diff --git a/workflows/bugfix/.claude/skills/pr/SKILL.md b/workflows/bugfix/.claude/skills/pr/SKILL.md
index e13a5c7..a637a32 100644
--- a/workflows/bugfix/.claude/skills/pr/SKILL.md
+++ b/workflows/bugfix/.claude/skills/pr/SKILL.md
@@ -5,15 +5,7 @@ description: Create a pull request from the current branch. Use this instead of
 
 # Create Pull Request Skill
 
-## Dispatch
-
-If you were dispatched by the controller or by speedrun, continue below.
-Otherwise, read `.claude/skills/controller/SKILL.md` first — it will send
-you back here with the proper workflow context.
-
----
-
-You are preparing to submit a bug fix as a pull request. This skill provides a
+You are preparing to submit changes as a pull request. This skill provides a
 systematic, failure-resistant process for getting code from the working directory
 into a PR. It handles the common obstacles: authentication, fork workflows,
 remote configuration, and cross-repo PR creation.
@@ -27,7 +19,7 @@ fallback ladder at the bottom of this file.
 
 ## Your Role
 
-Get the bug fix changes submitted as a draft pull request. Handle the full
+Get the changes submitted as a draft pull request. Handle the full
 git workflow: branch, commit, push, and PR creation. When steps fail, follow
 the documented recovery paths instead of guessing.
 
@@ -59,7 +51,7 @@ These are determined during pre-flight checks. Record each value as you go.
 | `FORK_OWNER` | Step 3: owner portion of fork's `nameWithOwner`, or `GH_USER` if newly created | `jsmith` |
 | `FORK_REMOTE` | Step 4: the git remote name pointing to the fork | `fork` / `origin` |
 | `REPO` | The repository name (without owner) | `myproject` |
-| `BRANCH_NAME` | Step 5: the branch you create | `bugfix/issue-42-null-check` |
+| `BRANCH_NAME` | Step 5: the branch you create | `feature/issue-42-auth-middleware` |
 
 ### Step 0: Determine Auth Context
 
@@ -129,7 +121,7 @@ checks above to set `AUTH_TYPE` and `GH_USER`.
 
 ### Step 1: Locate the Project Repository
 
-The bugfix workflow runs from the workflow directory, but the code changes live
+The workflow runs from the workflow directory, but the code changes live
 in the project repository. Before doing any git work:
 
 ```bash
@@ -163,7 +155,7 @@ git config user.email "GH_USER@users.noreply.github.com"
 ```
 
 - If missing and `gh` is NOT authenticated: set reasonable defaults so commits
-  work. Use `"bugfix-workflow"` / `"bugfix@workflow.local"` as placeholders.
+  work. Use `"workflow-agent"` / `"workflow@agent.local"` as placeholders.
 
 **2b. Inventory existing remotes:**
 
@@ -461,13 +453,17 @@ git rebase FORK_REMOTE/DEFAULT_BRANCH
 git checkout -b BRANCH_NAME
 ```
 
-Branch naming conventions:
+Branch naming conventions — choose the prefix that matches the work type:
+
+- `bugfix/issue-NUMBER-SHORT_DESCRIPTION` — bug fixes
+- `feature/issue-NUMBER-SHORT_DESCRIPTION` — new features
+- `refactor/SHORT_DESCRIPTION` — refactoring
+- `docs/SHORT_DESCRIPTION` — documentation changes
 
-- `bugfix/issue-NUMBER-SHORT_DESCRIPTION` if there's an issue number
-- `bugfix/SHORT_DESCRIPTION` if there's no issue number
-- Use kebab-case, keep it under 50 characters
+Use kebab-case, keep it under 50 characters. Include the issue number when one
+exists.
 
-If a branch already exists with the changes (from a prior `/fix` phase), use
+If a branch already exists with the changes (from a prior phase), use
 it instead of creating a new one.
 
 ### Step 6: Stage and Commit
@@ -476,22 +472,25 @@ Stage changes selectively (`git add path/to/files`, not `git add .`), review
 with `git status`, then commit using conventional commit format:
 
 ```bash
-git commit -m "fix(SCOPE): SHORT_DESCRIPTION
+git commit -m "TYPE(SCOPE): SHORT_DESCRIPTION
 
 DETAILED_DESCRIPTION
 
 Fixes #ISSUE_NUMBER"
 ```
 
-Use prior artifacts (root cause analysis, implementation notes) to write an
+Where `TYPE` matches the work: `fix`, `feat`, `refactor`, `docs`, `test`, etc.
+
+Use prior artifacts (analysis, implementation notes) to write an
 accurate commit message. Don't make up details.
 
 **Include the PR description in the commit body.** When a PR has a single
 commit, GitHub auto-fills the PR description from the commit message. This
 ensures the PR form is pre-populated even when `gh pr create` fails (a
-common case for bot environments). If `artifacts/bugfix/docs/pr-description.md`
-exists, append its content after the `Fixes #N` line. If it doesn't exist,
-compose a brief PR body from session context (problem, root cause, fix, testing)
+common case for bot environments). If a `docs/pr-description.md` artifact
+exists in the workflow's artifact directory, append its content after the
+`Fixes #N` line. If it doesn't exist,
+compose a brief PR body from session context (problem, approach, testing)
 and include that instead.
 
 ### Step 7: Push to Fork
@@ -532,8 +531,8 @@ gh pr create \
   --repo UPSTREAM_OWNER/REPO \
   --head FORK_OWNER:BRANCH_NAME \
   --base DEFAULT_BRANCH \
-  --title "fix(SCOPE): SHORT_DESCRIPTION" \
-  --body-file artifacts/bugfix/docs/pr-description.md
+  --title "TYPE(SCOPE): SHORT_DESCRIPTION" \
+  --body-file docs/pr-description.md
 ```
 
 `--head` must be `FORK_OWNER:BRANCH_NAME` format (with the owner prefix) for
@@ -545,8 +544,8 @@ composed from session artifacts.
 This is a common and expected outcome when running as a GitHub App bot.
 Do NOT retry, do NOT debug further, do NOT fall back to a patch file. Instead:
 
-1. **Write the PR description** to `artifacts/bugfix/docs/pr-description.md`
-   (if not already written).
+1. **Write the PR description** to `docs/pr-description.md` in the
+   workflow's artifact directory (if not already written).
 
 2. **Give the user a pre-filled GitHub compare URL** with `title` and `body`
    query parameters so the PR form opens fully populated:
@@ -607,7 +606,7 @@ Diagnose it using the Error Recovery table and retry.
 If `gh pr create` fails but the branch is pushed to the fork (this is a
 **common and expected** outcome when running as a GitHub App bot):
 
-1. **Write the PR body** to `artifacts/bugfix/docs/pr-description.md`
+1. **Write the PR body** to `docs/pr-description.md` in the artifact directory
 2. **Provide the compare URL with `title` and `body` query params** so the
    PR form opens fully populated (see Step 8 failure path for format)
 3. **Provide clone-and-checkout commands** for local testing
@@ -627,17 +626,17 @@ If no fork exists and automated forking fails:
 Only if ALL of the above fail — for example, the user has no GitHub account,
 or network access is completely blocked:
 
-1. Generate a patch: `git diff > bugfix.patch`
-2. Write it to `artifacts/bugfix/bugfix.patch`
-3. Explain to the user how to apply it: `git apply bugfix.patch`
+1. Generate a patch: `git diff > changes.patch`
+2. Write it to the workflow's artifact directory as `changes.patch`
+3. Explain to the user how to apply it: `git apply changes.patch`
 4. **Acknowledge this is a degraded experience** and explain what prevented
    the normal flow
 
 ## Output
 
 - The PR URL (printed to the user)
-- Optionally updates `artifacts/bugfix/docs/pr-description.md` if it didn't
-  already exist
+- Optionally writes `docs/pr-description.md` to the artifact directory if
+  it didn't already exist
 
 ## Usage Examples
 
@@ -676,13 +675,13 @@ or network access is completely blocked:
 
 ## Notes
 
-- This skill assumes the bug fix work (code changes, tests) is already done.
-  Run `/fix` and `/test` first.
-- If `/document` was run, the PR description artifact should already exist at
-  `artifacts/bugfix/docs/pr-description.md`. This skill will use it.
-- If `/document` was NOT run, this skill creates a minimal PR body from
-  session context (conversation history, prior artifacts).
-- The fork workflow is the standard for open source contributions. Even if the
+- This skill assumes the implementation work (code changes, tests) is already
+  done before invoking `/pr`.
+- If a `docs/pr-description.md` artifact already exists in the workflow's
+  artifact directory, this skill will use it.
+- If no PR description artifact exists, this skill creates a minimal PR body
+  from session context (conversation history, prior artifacts).
+- The fork workflow is the standard for open-source contributions. Even if the
   user has write access to upstream, using a fork keeps the upstream clean.
 
 ## When This Phase Is Done
@@ -693,4 +692,5 @@ Report your results:
 - What was included
 - Any follow-up actions needed (mark ready for review, add reviewers, etc.)
 
-Then announce which file you are returning to (e.g., "Returning to `.claude/skills/controller/SKILL.md`." or "Returning to `.claude/skills/speedrun/SKILL.md` for next phase.") and **re-read that file** for next-step guidance.
+Then return to the coordinating skill that dispatched you (if any) and
+**re-read that file** for next-step guidance.
diff --git a/workflows/dev-team/.claude/skills/pr/SKILL.md b/workflows/dev-team/.claude/skills/pr/SKILL.md
index 4ec6399..a637a32 100644
--- a/workflows/dev-team/.claude/skills/pr/SKILL.md
+++ b/workflows/dev-team/.claude/skills/pr/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: pr
-description: Create a pull request, handling fork workflows, authentication, and remote setup systematically.
+description: Create a pull request from the current branch. Use this instead of running gh pr create directly — it detects GitHub App vs user auth, finds or creates forks, syncs workflow files, detects the upstream default branch, and falls back to compare URLs when API access is limited.
 ---
 
 # Create Pull Request Skill
@@ -46,9 +46,12 @@ These are determined during pre-flight checks. Record each value as you go.
 | `AUTH_TYPE` | Step 0: `gh auth status` + `gh api user` | `user-token` / `github-app` / `none` |
 | `GH_USER` | Step 0: `gh api user` or `/installation/repositories` (for bots) | `jsmith` |
 | `UPSTREAM_OWNER/REPO` | Step 2c: `gh repo view --json nameWithOwner` | `acme/myproject` |
+| `DEFAULT_BRANCH` | Step 2c: detected from upstream repo | `main` / `dev` / `master` |
+| `UPSTREAM_REMOTE` | Step 2b: the git remote name pointing to the upstream org | `origin` / `upstream` |
 | `FORK_OWNER` | Step 3: owner portion of fork's `nameWithOwner`, or `GH_USER` if newly created | `jsmith` |
+| `FORK_REMOTE` | Step 4: the git remote name pointing to the fork | `fork` / `origin` |
 | `REPO` | The repository name (without owner) | `myproject` |
-| `BRANCH_NAME` | Step 5: the branch you create | `feature/add-auth-middleware` |
+| `BRANCH_NAME` | Step 5: the branch you create | `feature/issue-42-auth-middleware` |
 
 ### Step 0: Determine Auth Context
 
@@ -78,7 +81,43 @@ Record `GH_USER` and `AUTH_TYPE`:
 - If `gh api user` succeeded: `AUTH_TYPE` = `user-token`, `GH_USER` = the login
 - If `gh api user` failed but `/installation/repositories` worked:
   `AUTH_TYPE` = `github-app`, `GH_USER` = the repo owner login
-- If `gh auth status` itself failed: `AUTH_TYPE` = `none`
+- If `gh auth status` itself failed: try recovering from an expired token
+  (see below). If recovery fails: `AUTH_TYPE` = `none`
+
+**Recovering from expired tokens:** Platform sessions often start with a
+`GITHUB_TOKEN` env var that can expire mid-session. The `refresh_credentials`
+MCP tool refreshes the backend but does NOT update the shell env var. If
+`gh auth status` fails, check for a git credential helper:
+
+```bash
+git config --global credential.helper 2>/dev/null
+```
+
+If a credential helper exists (e.g., `/tmp/git-credential-ambient`), query it
+for a fresh token:
+
+```bash
+FRESH_TOKEN=$(printf 'protocol=https\nhost=github.com\n\n' | git credential fill 2>/dev/null | grep '^password=' | cut -d= -f2)
+```
+
+If that returns a token, export it and re-check auth:
+
+```bash
+export GITHUB_TOKEN="$FRESH_TOKEN"
+gh auth status
+```
+
+**Important:** Each shell invocation gets a fresh environment, so you must
+prepend the export to every subsequent `gh` command, or write the token to
+`~/.config/gh/hosts.yml` so `gh` picks it up natively:
+
+```bash
+gh auth login --with-token <<< "$FRESH_TOKEN"
+```
+
+The `gh auth login` approach is preferred — it persists for all subsequent
+`gh` commands without per-command exports. After recovery, re-run the identity
+checks above to set `AUTH_TYPE` and `GH_USER`.
 
 ### Step 1: Locate the Project Repository
 
@@ -116,7 +155,7 @@ git config user.email "GH_USER@users.noreply.github.com"
 ```
 
 - If missing and `gh` is NOT authenticated: set reasonable defaults so commits
-  work. Use `"dev-team-workflow"` / `"dev-team@workflow.local"` as placeholders.
+  work. Use `"workflow-agent"` / `"workflow@agent.local"` as placeholders.
 
 **2b. Inventory existing remotes:**
 
@@ -134,21 +173,33 @@ the user's fork. Common patterns:
 | `fork` | user's name | Fork (read-write) |
 | `upstream` | upstream org | Upstream (read-only) |
 
-**2c. Identify the upstream repo:**
+**2c. Identify the upstream repo and its default branch:**
 
 If `gh` is authenticated:
 
 ```bash
-gh repo view --json nameWithOwner --jq .nameWithOwner
+gh repo view --json nameWithOwner,defaultBranchRef --jq '{nameWithOwner, defaultBranch: .defaultBranchRef.name}'
 ```
 
-If `gh` is NOT authenticated, extract from the git remote URL:
+This returns both the repo name and its default branch. Record
+`UPSTREAM_OWNER/REPO` and `DEFAULT_BRANCH` from the output.
+
+If `gh` is NOT authenticated, extract from the upstream remote (identified in
+Step 2b as `UPSTREAM_REMOTE`):
 
 ```bash
-git remote get-url origin | sed -E 's#.*/([^/]+/[^/]+?)(\.git)?$#\1#'
+# Repo name (use UPSTREAM_REMOTE, not necessarily origin — origin may be the fork)
+git remote get-url UPSTREAM_REMOTE | sed -E 's#.*/([^/]+/[^/]+?)(\.git)?$#\1#'
+
+# Default branch
+git remote show UPSTREAM_REMOTE 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}'
 ```
 
-Record the result as `UPSTREAM_OWNER/REPO` — you'll need it later.
+Record the results as `UPSTREAM_OWNER/REPO` and `DEFAULT_BRANCH`.
+
+**Do not assume the default branch is `main`.** Many projects use `dev`,
+`master`, `develop`, or other branch names. All subsequent steps that
+reference the base branch MUST use `DEFAULT_BRANCH`.
 
 **2d. Check current branch and changes:**
 
@@ -173,6 +224,8 @@ Pre-flight summary:
 | AUTH_TYPE             | ___                |
 | GH_USER              | ___                |
 | UPSTREAM_OWNER/REPO  | ___                |
+| DEFAULT_BRANCH       | ___                |
+| UPSTREAM_REMOTE      | ___                |
 | EXISTING_REMOTES     | ___                |
 | HAS_CHANGES          | yes / no           |
 | CURRENT_BRANCH       | ___                |
@@ -305,8 +358,15 @@ If not present, add it:
 git remote add fork https://github.com/FORK_OWNER/REPO.git
 ```
 
-Use `fork` as the remote name. If `origin` already points to the fork, that's
-fine — just use `origin` in subsequent commands instead of `fork`.
+**Set `FORK_REMOTE`** based on what you find:
+
+- If you just added a remote named `fork` → `FORK_REMOTE` = `fork`
+- If `origin` already points to the fork (URL contains `FORK_OWNER`) →
+  `FORK_REMOTE` = `origin`
+- If another existing remote points to the fork → `FORK_REMOTE` = that name
+
+Record `FORK_REMOTE` now. **Use it in all subsequent commands** (push, fetch,
+ls-remote) instead of hardcoding `fork` or `origin`.
 
 ### Step 4a: Check Fork Sync Status
 
@@ -327,12 +387,13 @@ permission by design.
 **Detection:**
 
 ```bash
-# Fetch the fork to get its current state
-git fetch fork
+# Fetch both the fork and the upstream remote (identified in Step 2b)
+git fetch FORK_REMOTE
+git fetch UPSTREAM_REMOTE
 
-# Check for workflow file differences between fork/main and local main
-# (local main should be synced with upstream)
-WORKFLOW_DIFF=$(git diff fork/main..main -- .github/workflows/ --name-only 2>/dev/null)
+# Compare fork's DEFAULT_BRANCH against upstream's DEFAULT_BRANCH
+# (don't rely on the local branch — it may be stale)
+WORKFLOW_DIFF=$(git diff --name-only FORK_REMOTE/DEFAULT_BRANCH..UPSTREAM_REMOTE/DEFAULT_BRANCH -- .github/workflows/ 2>/dev/null)
 
 if [ -n "$WORKFLOW_DIFF" ]; then
   echo "Fork is out of sync with upstream (workflow files differ):"
@@ -340,14 +401,18 @@ if [ -n "$WORKFLOW_DIFF" ]; then
 fi
 ```
 
+`UPSTREAM_REMOTE` is whichever remote was identified as pointing to the
+upstream org in Step 2b (typically `origin` when origin is the upstream repo,
+or `upstream` if the user added it separately).
+
 **If workflow differences exist — attempt automated sync:**
 
 ```bash
-# Try to sync the fork's main branch with upstream
-gh api --method POST repos/FORK_OWNER/REPO/merge-upstream -f branch=main
+# Try to sync the fork's default branch with upstream
+gh api --method POST repos/FORK_OWNER/REPO/merge-upstream -f branch=DEFAULT_BRANCH
 ```
 
-- If this succeeds: fetch the fork again (`git fetch fork`) and continue
+- If this succeeds: fetch the fork again (`git fetch FORK_REMOTE`) and continue
 - If this fails (usually due to workflow permission restrictions): guide the
   user to sync manually
 
@@ -364,7 +429,7 @@ gh api --method POST repos/FORK_OWNER/REPO/merge-upstream -f branch=main
 >
 > 2. **Via command line** (may require `gh auth refresh -s workflow` first):
 >    ```
->    gh repo sync FORK_OWNER/REPO --branch main
+>    gh repo sync FORK_OWNER/REPO --branch DEFAULT_BRANCH
 >    ```
 >
 > Let me know when the sync is complete and I'll continue with the PR.
@@ -373,12 +438,13 @@ gh api --method POST repos/FORK_OWNER/REPO/merge-upstream -f branch=main
 
 ```bash
 # Fetch the updated fork
-git fetch fork
+git fetch FORK_REMOTE
 
-# Rebase the feature branch onto the synced fork/main
-git rebase fork/main
+# Update local DEFAULT_BRANCH before creating the feature branch
+git checkout DEFAULT_BRANCH
+git rebase FORK_REMOTE/DEFAULT_BRANCH
 
-# Continue to Step 5 (create branch)
+# Continue to Step 5 (create feature branch from updated DEFAULT_BRANCH)
 ```
 
 ### Step 5: Create a Branch
@@ -387,13 +453,18 @@ git rebase fork/main
 git checkout -b BRANCH_NAME
 ```
 
-Branch naming conventions:
+Branch naming conventions — choose the prefix that matches the work type:
 
-- Use a descriptive prefix: `feature/`, `bugfix/`, `refactor/`, `docs/`, etc.
-- Include an issue number if one exists: `feature/issue-42-auth-middleware`
-- Use kebab-case, keep it under 50 characters
+- `bugfix/issue-NUMBER-SHORT_DESCRIPTION` — bug fixes
+- `feature/issue-NUMBER-SHORT_DESCRIPTION` — new features
+- `refactor/SHORT_DESCRIPTION` — refactoring
+- `docs/SHORT_DESCRIPTION` — documentation changes
 
-If a branch already exists with the changes, use it instead of creating a new one.
+Use kebab-case, keep it under 50 characters. Include the issue number when one
+exists.
+
+If a branch already exists with the changes (from a prior phase), use
+it instead of creating a new one.
 
 ### Step 6: Stage and Commit
 
@@ -401,17 +472,26 @@ Stage changes selectively (`git add path/to/files`, not `git add .`), review
 with `git status`, then commit using conventional commit format:
 
 ```bash
-git commit -m "type(scope): short description
+git commit -m "TYPE(SCOPE): SHORT_DESCRIPTION
 
-Detailed description of what changed and why.
+DETAILED_DESCRIPTION
 
 Fixes #ISSUE_NUMBER"
 ```
 
+Where `TYPE` matches the work: `fix`, `feat`, `refactor`, `docs`, `test`, etc.
+
+Use prior artifacts (analysis, implementation notes) to write an
+accurate commit message. Don't make up details.
+
 **Include the PR description in the commit body.** When a PR has a single
 commit, GitHub auto-fills the PR description from the commit message. This
 ensures the PR form is pre-populated even when `gh pr create` fails (a
-common case for bot environments).
+common case for bot environments). If a `docs/pr-description.md` artifact
+exists in the workflow's artifact directory, append its content after the
+`Fixes #N` line. If it doesn't exist,
+compose a brief PR body from session context (problem, approach, testing)
+and include that instead.
 
 ### Step 7: Push to Fork
 
@@ -419,8 +499,8 @@ common case for bot environments).
 # Ensure git uses gh for authentication
 gh auth setup-git
 
-# Push the branch
-git push -u fork BRANCH_NAME
+# Push the branch (use FORK_REMOTE from Step 4)
+git push -u FORK_REMOTE BRANCH_NAME
 ```
 
 **If this fails:**
@@ -430,7 +510,7 @@ git push -u fork BRANCH_NAME
   re-authenticate or the sandbox may be blocking network access.
 - **Remote not found**: Verify the fork remote URL is correct.
 - **Permission denied**: The fork remote may be pointing to upstream, not the
-  actual fork. Verify with `git remote get-url fork`.
+  actual fork. Verify with `git remote get-url FORK_REMOTE`.
 
 ### Step 8: Create the Draft PR
 
@@ -450,34 +530,38 @@ gh pr create \
   --draft \
   --repo UPSTREAM_OWNER/REPO \
   --head FORK_OWNER:BRANCH_NAME \
-  --base main \
-  --title "type(scope): short description" \
-  --body "PR description here"
+  --base DEFAULT_BRANCH \
+  --title "TYPE(SCOPE): SHORT_DESCRIPTION" \
+  --body-file docs/pr-description.md
 ```
 
 `--head` must be `FORK_OWNER:BRANCH_NAME` format (with the owner prefix) for
-cross-fork PRs.
+cross-fork PRs. If `--body-file` doesn't exist, use `--body` with content
+composed from session artifacts.
 
 **If `gh pr create` fails (403, "Resource not accessible by integration", etc.):**
 
 This is a common and expected outcome when running as a GitHub App bot.
 Do NOT retry, do NOT debug further, do NOT fall back to a patch file. Instead:
 
-1. **Give the user a pre-filled GitHub compare URL** with `title` and `body`
+1. **Write the PR description** to `docs/pr-description.md` in the
+   workflow's artifact directory (if not already written).
+
+2. **Give the user a pre-filled GitHub compare URL** with `title` and `body`
    query parameters so the PR form opens fully populated:
 
    ```text
-   https://github.com/UPSTREAM_OWNER/REPO/compare/main...FORK_OWNER:BRANCH_NAME?expand=1&title=URL_ENCODED_TITLE&body=URL_ENCODED_BODY
+   https://github.com/UPSTREAM_OWNER/REPO/compare/DEFAULT_BRANCH...FORK_OWNER:BRANCH_NAME?expand=1&title=URL_ENCODED_TITLE&body=URL_ENCODED_BODY
    ```
 
    URL-encode the title and body. If the encoded URL would exceed ~8KB
    (browser limit), omit the `body` parameter — the commit message body
    from Step 6 will still auto-fill the description for single-commit PRs.
 
-2. **Remind the user** to check "Create draft pull request" if they want
+3. **Remind the user** to check "Create draft pull request" if they want
    it as a draft.
 
-3. **Provide clone-and-checkout commands** so the user can test locally:
+4. **Provide clone-and-checkout commands** so the user can test locally:
 
    ```text
    ## Test the branch locally
@@ -494,7 +578,7 @@ Do NOT retry, do NOT debug further, do NOT fall back to a patch file. Instead:
    ```
 
 **If "branch not found"**: The push in Step 7 may have failed silently.
-Verify with `git ls-remote fork BRANCH_NAME`.
+Verify with `git ls-remote FORK_REMOTE BRANCH_NAME`.
 
 ### Step 9: Confirm and Report
 
@@ -522,10 +606,11 @@ Diagnose it using the Error Recovery table and retry.
 If `gh pr create` fails but the branch is pushed to the fork (this is a
 **common and expected** outcome when running as a GitHub App bot):
 
-1. **Provide the compare URL with `title` and `body` query params** so the
+1. **Write the PR body** to `docs/pr-description.md` in the artifact directory
+2. **Provide the compare URL with `title` and `body` query params** so the
    PR form opens fully populated (see Step 8 failure path for format)
-2. **Provide clone-and-checkout commands** for local testing
-3. **Note**: between the commit message body (Step 6) and the URL params,
+3. **Provide clone-and-checkout commands** for local testing
+4. **Note**: between the commit message body (Step 6) and the URL params,
    the user should see the PR description auto-filled with no manual copying
 
 ### Rung 3: User creates fork, you push and PR
@@ -542,7 +627,7 @@ Only if ALL of the above fail — for example, the user has no GitHub account,
 or network access is completely blocked:
 
 1. Generate a patch: `git diff > changes.patch`
-2. Write it to an artifacts directory
+2. Write it to the workflow's artifact directory as `changes.patch`
 3. Explain to the user how to apply it: `git apply changes.patch`
 4. **Acknowledge this is a degraded experience** and explain what prevented
    the normal flow
@@ -550,10 +635,12 @@ or network access is completely blocked:
 ## Output
 
 - The PR URL (printed to the user)
+- Optionally writes `docs/pr-description.md` to the artifact directory if
+  it didn't already exist
 
 ## Usage Examples
 
-**After completing work:**
+**After completing the workflow:**
 
 ```text
 /pr
@@ -562,7 +649,13 @@ or network access is completely blocked:
 **With a specific issue reference:**
 
 ```text
-/pr Fixes #47 - add auth middleware
+/pr Fixes #47 - include all documented tool types in OpenAPI spec
+```
+
+**When the fork is already set up:**
+
+```text
+/pr --repo openresponses/openresponses
 ```
 
 ## Error Recovery Quick Reference
@@ -570,6 +663,7 @@ or network access is completely blocked:
 | Symptom | Cause | Fix |
 | --- | --- | --- |
 | `gh auth status` fails | Not logged in | User must run `gh auth login` |
+| `gh` commands return 401 "Bad credentials" | `GITHUB_TOKEN` expired mid-session | Query git credential helper for fresh token, then `gh auth login --with-token` (see Step 0 recovery) |
 | `git push` "could not read Username" | git credential helper not configured | Run `gh auth setup-git` then retry push |
 | `git push` permission denied | Pushing to upstream, not fork | Verify remote URL, switch to fork |
 | `git push` "refusing to allow...without `workflows` permission" | Fork out of sync with upstream (missing workflow files) | Run Step 4a: sync fork, then rebase and retry push |
@@ -577,11 +671,26 @@ or network access is completely blocked:
 | `gh repo fork` fails | Sandbox blocks forking | User creates fork manually |
 | Branch not found on remote | Push failed silently | Re-run `git push`, check network |
 | No changes to commit | Changes already committed or not staged | Check `git status`, `git log` |
-| Wrong base branch | Upstream default isn't `main` | Check with `gh repo view --json defaultBranchRef` |
+| Wrong base branch | `DEFAULT_BRANCH` wasn't detected or was overridden | Re-run `gh repo view --json defaultBranchRef` and update `DEFAULT_BRANCH` |
 
 ## Notes
 
 - This skill assumes the implementation work (code changes, tests) is already
-  done.
-- The fork workflow is the standard for open source contributions. Even if the
+  done before invoking `/pr`.
+- If a `docs/pr-description.md` artifact already exists in the workflow's
+  artifact directory, this skill will use it.
+- If no PR description artifact exists, this skill creates a minimal PR body
+  from session context (conversation history, prior artifacts).
+- The fork workflow is the standard for open-source contributions. Even if the
   user has write access to upstream, using a fork keeps the upstream clean.
+
+## When This Phase Is Done
+
+Report your results:
+
+- PR URL (or manual creation URL if automated creation wasn't possible)
+- What was included
+- Any follow-up actions needed (mark ready for review, add reviewers, etc.)
+
+Then return to the coordinating skill that dispatched you (if any) and
+**re-read that file** for next-step guidance.