菜单
Use after all requirements are complete to delete consumed plan docs, curate lessons, update documentation, and ship the work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores intent and design before implementation. Use this skill whenever the user describes something they want to build, change, or improve, even if they don't say 'brainstorm' — phrases like 'I want to add X', 'let's build Y', 'we need a way to Z', or 'help me design' all apply.
Review a completed requirement's code — trace the logic, check spec alignment against the acceptance criteria, fix code smells, and run a production hazard check. Runs after each requirement in pwk-executing-tasks. Unlocked: may edit code to apply smell fixes.
Turn a design doc's requirements into a behavioral spec — acceptance criteria + integration tests per requirement. Use after pwk-brainstorming, before pwk-executing-tasks. Use when the user says 'let's plan', 'write a plan', 'break this down', or after a brainstorm when ready to move to implementation.
Disciplined debugging loop for hard bugs and performance regressions. Use when a test fails unexpectedly, a bug is found during execution, or something is broken. Use this skill whenever the user reports a bug, says 'this doesn't work', 'something's wrong', 'help me debug', or when tests fail for unclear reasons. Works at any point in the workflow — brainstorm, execute, or standalone.
Implement a plan requirement-by-requirement with test-first discipline and full autonomy. Run after pwk-writing-plans. Each requirement: write integration tests (red) → checkpoint → implement to green → checkpoint → pwk-code-review.
Show all active pipeline topics and their phase/progress. Use when the user asks 'where are we', 'status', 'what's in flight', or when resuming and unsure which design to continue. Read-only discovery. Not a pipeline phase.
| name | pwk-finalizing |
| description | Use after all requirements are complete to delete consumed plan docs, curate lessons, update documentation, and ship the work. |
Ship the completed work.
/skill:pwk-executing-tasks.docs/plans/*-progress.md):
❌ failed → block. Present counts and reasons; continue only when the user sends the task back to executing-tasks, or explicitly types --force-failed to acknowledge shipping with incomplete requirements.⏭ skipped → warn and confirm ("Requirement N was skipped. Continue, or go back?").Derive the topic — progress file → Plan: ref → plan's Design: ref → design-doc filename → <topic>. Ambiguous with several designs in flight? Ask.
Delete consumed plan docs — only this design's three artifacts, matched by the exact topic slug (with the YYYY-MM-DD- prefix) so similarly-named plans for other topics survive:
rm -f docs/plans/????-??-??-<topic>-design.md docs/plans/????-??-??-<topic>-implementation.md docs/plans/????-??-??-<topic>-progress.md
The ????-??-??- glob enforces the dated filename; a bare *<topic>* would over-match unrelated docs (e.g. topic auth would also hit feature-auth-redesign-design.md). Verify with ls docs/plans/ before and after. rm -f handles missing files. docs/adr/, docs/lessons.md, CHANGELOG.md, and README.md are permanent — leave them entirely out of the delete set.
Curate lessons (Agile Scrum Master hat) — if docs/lessons.md exists: add missed lessons, generalize domain-specific rules into generic patterns, de-duplicate, categorize, retire stale rules. None exists but lessons were learned? Create it.
Update documentation — if the API or surface changed: README.md, CHANGELOG.md, any inline docs.
Choose a merge strategy — ask the human:
git push origin <branch> then gh pr create.--ff-only merge, push parent, delete branch.--no-ff merge, push parent, delete branch.For 2–4, confirm the detected parent branch before proceeding.
Clean up — remove the worktree if one was used: git worktree remove ../<repo>-<topic>.
docs/plans/.