菜单
After a development PR is merged, sync with origin, switch to the merged PR's base branch, pull, verify or delete the remote implementation branch, delete the local branch, and update the related issue in the issue tracker. Use when you want to clean up the local repo post-merge.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Run a retrospective analysis on completed work to identify process improvement opportunities. Use when the user wants to review a completed batch or item run, or invoke on-demand with a PR number, branch, or date as scope hint.
Compatibility/advanced alias: resolve a native GitHub epic into a bounded workflow execution scope, with optional delegated review and merge gates. For the recommended starting point, use /run-work <epic-target> instead. Use /run-epic when you need direct control over delegation flags (--delegate-review, --may-merge, --max-risk). For explicit item lists, use /run-items.
Bounded multi-item execute command: advance two or more explicit workflow items through Protocol 90 explicit_list mode. For a single item use $run-item; for an epic use $run-epic; for a read-only portfolio scan use $run-work.
Read-only portfolio scan. No-target scan proposes batches with no dispatch. Two or more targets redirect to $run-items. Single targets redirect to $run-item or $run-epic. No mutation in any mode.
Batch-orchestrate the repository's staged AI development workflow. Use when the user wants Codex to discover what can advance or start across multiple items, propose the largest safe batch by priority and parallelization feasibility, and supervise approved item work until it reaches a real terminal condition.
Primary bounded command: advance exactly one non-epic workflow item. Use when the user asks for /run-item or wants to resume a specific development, branch, PR, or issue with the shared bounded prelude before Protocol 91. /run-item-work is a deprecated alias with identical behavior.
| name | post-merge-cleanup |
| description | After a development PR is merged, sync with origin, switch to the merged PR's base branch, pull, verify or delete the remote implementation branch, delete the local branch, and update the related issue in the issue tracker. Use when you want to clean up the local repo post-merge. |
From the repository root, run:
./scripts/development-workflow/post-merge-cleanup.sh [--base base-branch] [branch-name]
No argument: the current branch is the one to delete (user runs while still on the merged branch).
With branch-name: delete that local branch (e.g. feature/my-feature).
With --base base-branch: explicitly choose the cleanup base branch. When omitted for hub-owned cleanup, the script queries the merged PR base and fails closed if that lookup is unavailable.
In workflow_hub, preserve the selected product repository context for product-owned implementation cleanup and pass it through to shared cleanup helpers; hub-owned spec, plan, and workflow PR cleanup remains in the hub. Missing mode or single_repo keeps current cleanup behavior.
Update the issue tracker (if configured)
The merged branch name often contains an issue identifier (e.g. feature/ENG-123-user-auth → ENG-123, fix/PROJ-456-login → PROJ-456, feature/42-user-auth → #42). After the script succeeds, update the corresponding issue using the branch-type-based status table from Step 10 of docs/workflow/development-workflow/protocols/91-orchestrate-work-protocol.md:
| Merged branch type | Set tracker status to |
|---|---|
spec/* | Spec Ready |
implementation-plan/* | Plan Ready |
feature/* / fix/* / refactor/* / hotfix/* | Merged |
If the item’s tracker status is already in a further-advanced state (e.g., already In Development when a spec branch merges), do not roll it back — leave it as-is.
docs/workflow/development-workflow/integrations/linear.md).gh CLI / GraphQL (per docs/workflow/development-workflow/integrations/github-projects.md).docs/workflow/development-workflow/integrations/issue-tracker.md and the tracker-specific doc under docs/workflow/development-workflow/integrations/.For implementation branches (feature/*, fix/*, refactor/*,
hotfix/*), verify the script reports REMOTE_DELETE_RESULT=deleted or
REMOTE_DELETE_RESULT=not_found before claiming cleanup complete. A
skipped or failed remote deletion result is non-terminal. Spec and
implementation-plan branches are expected-persistent remotely.
Before reporting cleanup or tracker reconciliation complete for a workflow
item, run scripts/development-workflow/item-completion-self-check.sh with
--stage cleanup and the expected tracker status when claimed. Include its
## Ground-Truth Completion Verification section in the cleanup report; a
discrepancy or unavailable_required result means cleanup is not complete.
After cleanup and tracker update — suggest a retrospective if appropriate: If this post-merge cleanup is the final action for a work item that was advanced in the current session (i.e., you drove the item through implementation, review, and merge in this conversation), suggest running a retrospective:
Would you like to run a retrospective on this session’s work?
Only suggest this when the cleanup is for a standalone item run (not when called as part of a batch merge or orchestrator flow, which handle retrospectives at their own level). See docs/workflow/development-workflow/protocols/06-retrospective-protocol.md.
The script (step 1) fetches origin, checks out the merged PR's base branch, pulls, verifies or deletes the remote implementation branch after confirming the PR is merged, deletes the local branch with git branch -D (force-delete; safe because the branch is already merged on the remote), and for implementation branches (fix/*, feature/*, hotfix/*, refactor/*) automatically closes the associated GitHub issue if a merged PR is found. Do not change the order or skip steps.