diff --git a/cloudflare-gastown/src/prompts/mayor-system.prompt.ts b/cloudflare-gastown/src/prompts/mayor-system.prompt.ts
index 10ce483c4e..78c3b6d347 100644
--- a/cloudflare-gastown/src/prompts/mayor-system.prompt.ts
+++ b/cloudflare-gastown/src/prompts/mayor-system.prompt.ts
@@ -284,6 +284,26 @@ For large convoys (>5 beads) where the decomposition is non-obvious, consider
 using staged=true by default to give the user a chance to review before agents
 start spending compute.
 
+## PR Fixup Dispatch
+
+When you need to dispatch a polecat to fix PR review comments or CI failures on an existing PR:
+
+1. Use \`gt_sling\` with the \`labels\` parameter set to \`["gt:pr-fixup"]\`
+2. Include the PR URL, branch name, and target branch in the bead metadata:
+   \`\`\`
+   metadata: {
+     pr_url: "https://github.com/org/repo/pull/123",
+     branch: "gt/toast/abc123",
+     target_branch: "main"
+   }
+   \`\`\`
+3. In the bead body, include:
+   - The PR URL
+   - What needs fixing (specific review comments, CI failures, etc.)
+   - The branch to work on
+
+The \`gt:pr-fixup\` label causes the bead to skip the review queue when the polecat calls gt_done — the work goes directly to the existing PR branch without creating a separate review cycle.
+
 ## Bug Reporting
 
 If a user reports a bug or you encounter a repeating error, you can file a bug report
diff --git a/cloudflare-gastown/src/prompts/polecat-system.prompt.ts b/cloudflare-gastown/src/prompts/polecat-system.prompt.ts
index ea57e1077b..dc45e8f45c 100644
--- a/cloudflare-gastown/src/prompts/polecat-system.prompt.ts
+++ b/cloudflare-gastown/src/prompts/polecat-system.prompt.ts
@@ -58,12 +58,26 @@ You have these tools available. Use them to coordinate with the Gastown orchestr
 4. **Checkpoint**: After significant milestones, call gt_checkpoint with a summary of progress.
 5. **Done**: When the bead is complete, push your branch and call gt_done with the branch name. The bead transitions to \`in_review\` and the refinery picks it up for merge. If the review fails (rework), you will be re-dispatched with the bead back in \`in_progress\`.
 ${gatesSection}
+## PR Fixup Workflow
+
+When your hooked bead has the \`gt:pr-fixup\` label, you are fixing an existing PR rather than creating new work. **This is the ONE exception to the "do not switch branches" rule.** You MUST check out the PR branch from your bead metadata instead of using the default worktree branch.
+
+1. Check out the PR branch specified in your bead metadata (e.g. \`git fetch origin <branch> && git checkout <branch>\`). This overrides the default worktree branch for this bead.
+2. Look at ALL comments on the PR using \`gh pr view <number> --comments\` and the GitHub API.
+3. For each review comment thread:
+   - If the comment is actionable: fix the issue, push the fix, reply explaining how you fixed it, and resolve the thread.
+   - If the comment is not relevant or is incorrect: reply explaining why, and resolve the thread.
+4. **Important**: Resolve the entire thread, not just the individual comment. Use \`gh api\` to resolve review threads.
+5. After addressing all comments, push your changes and call gt_done.
+
+Do NOT create a new PR. Push to the existing branch.
+
 ## Commit & Push Hygiene
 
 - Commit after every meaningful unit of work (new function, passing test, config change).
 - Push after every commit. Do not batch pushes.
 - Use descriptive commit messages referencing the bead if applicable.
-- Branch naming: your branch is pre-configured in your worktree. Do not switch branches.
+- Branch naming: your branch is pre-configured in your worktree. Do not switch branches — **unless** your bead has the \`gt:pr-fixup\` label (see PR Fixup Workflow above).
 
 ## Escalation