plan-to-implementation

Plan to Implementation

Resume a plan from an existing draft PR, execute it with SDD, and flip that same PR ready. The PR description, its single marked plan comment, and the pushed branch are the durable state. Never recreate the planning session and never call gh pr create from this skill. Exact commands: rehydrate-and-finish.md.

Invoking this skill means the user has reviewed and approved the complete marked plan comment and selected this repository's SDD workflow. Do not ask for plan approval again before dispatch. Subagent-driven development is the sole execution mode. Never expose, recommend, or invoke Native superpowers:executing-plans from this workflow, even when upstream offers it or cost pressure favors it.

Rehydrate (every fresh entry — all 6 steps, in order)

1. Resolve the single open draft PR that closes the issue and has exactly one comment containing <!-- BEGIN PLAN -->. Zero or multiple matches — PRs or marker-bearing comments: stop and report; never guess or match by title.
2. Verify the linked issue is finalized: no [DRAFT] prefix, and no Next: line in its ## Brainstorm state section (a revision still in progress). If not, stop and report — route it back to brainstorming-to-issue #N.
3. Verify that one PR comment contains exactly one ordered BEGIN PLAN/END PLAN marker pair — not the PR description.
4. Resolve the worktree from the PR's headRefName. Never ask about worktrees — always isolate. Exactly one worktree on that branch: enter it. No match: create one for that existing branch per superpowers:using-git-worktrees (native tool preferred, else .worktrees/<branch>), never a new feature branch, never a consent prompt. More than one match: stop and report — two worktrees on one branch is broken state, not a preference question. A failing baseline is likewise a stop, not a question. Run gh pr checkout <M> inside the resolved worktree.
5. Extract only the marker-delimited text from that comment into .superpowers/sdd/plan.md — never stale local scratch, never surrounding comment prose, never the PR description.
6. If .superpowers/sdd/plan/progress.md exists, preserve it and resume from it; else start at Task 1.

Execute

Pre-dispatch gate — before dispatching any task, confirm each check aloud:

1. Linked issue is finalized (no [DRAFT] prefix, no Next: line in ## Brainstorm state).
2. The plan comment had exactly one ordered marker pair.
3. Plan compared against the issue — conflicts take the conflict path below.

REQUIRED SUB-SKILL: superpowers:subagent-driven-development with .superpowers/sdd/plan.md. Never synchronously ask or wait for a human; use the paths below.

Pre-flight conflict → self-heal exactly once

1. Regenerate the plan from the issue via superpowers:writing-plans; update both local plan.md and the PR's marked plan comment — edit that comment in place by its comment ID, never repost it; re-run pre-flight review.
2. Still conflicted (specification defect; nothing implemented yet): gh pr close <M> --delete-branch; prefix the issue title [DRAFT]; comment the specific conflicts; unassign and remove in-progress; stop — route back to brainstorming-to-issue. Never regenerate twice or implement around the conflict.

Mid-execution blocker (implementer BLOCKED, or review finding needs a human — all 6 steps, in order)

1. Stop dispatching tasks.
2. Prepend ## ⚠️ Blocked — needs human decision to the existing draft PR description. Per blocker state: the task, the reason/finding, the conflicting plan text, and the exact decision needed.
3. In that same description, report honest progress status AND test status; keep Closes #N and the summary intact. The plan comment is separate and stays untouched.
4. Push committed work. Keep the PR draft; keep the issue assigned and in-progress.
5. Skip the final whole-branch review and the tests-must-pass gate — never force a blocked branch through success gates.
6. Stop. Never open a second PR or reset the issue for a blocker.

Successful finish (all 6 steps, in order)

1. REQUIRED SUB-SKILL: invoke superpowers:finishing-a-development-branch for its verification and cleanup.
2. Override inside that sub-skill: skip its completion menu and never create a new PR.
3. Inspect both the implementation plan and final review result for an explicit manual-verification requirement. State the result from each source separately before continuing.
4. If manual verification is required, add or update ## Manual testing in the existing PR description with concrete reviewer steps and the expected result for each step. Preserve the summary, Closes #N, test plan, and all other reviewer-facing content; leave the marked plan comment unchanged. Re-fetch and verify the description. Evaluate the gate after attempting this update: a missing, vague, unverified, or comment-only handoff blocks the ready transition. A request to omit or defer the section is not itself a blocker after a compliant description is verified; continue to step 5. If neither source requires manual verification, leave the description unchanged and continue to step 5.
5. Push the branch, then run gh pr ready <M> on the existing draft PR — in that order.
6. Keep the worktree, per the sub-skill's normal PR path.

Common Mistakes

Mistake	Required correction
Asking whether to create a worktree	The preference is declared: always isolate, never ask

Red Flags — STOP

• More than one worktree has the PR branch checked out.

Any red flag means: stop and report instead of asking or guessing — an ambiguous worktree is state to fix, not a question to put to a human.