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

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

Resolve the single open draft PR that closes the issue and has exactly one comment containing
```

```
. Zero or multiple matches — PRs or marker-bearing comments: stop and report; never guess or match by title.
Verify the linked issue is finalized (no
```
[DRAFT]
```
prefix); if not, stop and report.
Verify that one PR comment contains exactly one ordered
```
BEGIN PLAN
```
/
```
END PLAN
```
marker pair — not the PR description.
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.
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.
If
```
.superpowers/sdd/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:

Linked issue is finalized (no
```
[DRAFT]
```
prefix).
The plan comment had exactly one ordered marker pair.
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

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.
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)

Stop dispatching tasks.
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.
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.
Push committed work. Keep the PR draft; keep the issue assigned and
```
in-progress
```
.
Skip the final whole-branch review and the tests-must-pass gate — never force a blocked branch through success gates.
Stop. Never open a second PR or reset the issue for a blocker.

Successful finish (all 6 steps, in order)

REQUIRED SUB-SKILL: invoke
```
superpowers:finishing-a-development-branch
```
for its verification and cleanup.
Override inside that sub-skill: skip its completion menu and never create a new PR.
Inspect both the implementation plan and final review result for an explicit manual-verification requirement. State the result from each source separately before continuing.
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.
Push the branch, then run
```
gh pr ready <M>
```
on the existing draft PR — in that order.
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.

plan-to-implementation

NPX Install

Tags

SKILL.md Content