Plan

Turn an issue into a plan plus a living end-to-end execution checklist the human can watch from start to finish. Invoke it on any issue: read the issue, confirm scope, draft a short narrative plan, then build one checklist that covers the whole road to done, from writing code through review, merge, deploy, and cleanup, and push it into the agent's real todo surface so it stays live as the work runs.

The point is not a tidy document. It is that the plan becomes a contract you can watch and add to: every step is verifiable, each "it works" step carries the evidence that proves it, and the human-review gates are on the list from the start rather than remembered at the end.

Planning applies sibling disciplines rather than restating them:

• Living E2E Checklist keeps the checklist live: one list, always current.
• Proof of Work makes each step show evidence instead of asserting success.

A plan is intent, the Living E2E Checklist is live status, Proof of Work is evidence, and review gates are where a human consumes that evidence. They are the moments of one per-item loop: plan the step, do it, prove it, gate it, check it off.

See Plan Example for a filled-in plan and checklist.

When to use

Invoke it (ask to "plan this issue") when you are about to start real work and want a scoped, verifiable, watchable checklist before building: a fresh issue, a multi-step change, or picking up in-flight work.

Skip it for a trivial one-line change (just do it) and for pure research with no implementation. It is not a status summary (use the recap skill) or a look back (use the retrospective skill); it looks forward and produces the list the other two read from.

Procedure

1. Anchor and scope. Read the issue in full. Restate it as #<N>: <title> so the plan is scannable. Confirm the scope and acceptance criteria, and ask the human when anything is ambiguous rather than guessing. Say plainly what is out of scope.
2. Gather context. Learn what you are walking into before planning: the existing branch, worktree, and PR state, plus the repo's conventions and test and build commands. Reuse the begin-work and issue-dashboard patterns from the GitHub skill rather than re-deriving them here.
3. Draft the narrative plan. A few short paragraphs: the problem, the approach, key decisions and trade-offs, and any open questions. Keep it prose; the checklist below carries the steps.
4. Build the end-to-end checklist. Turn the approach into one item per verifiable step on the lifecycle spine (below). Start from the full spine so the tail (deploy, cleanup) is on the list from the beginning. Draw Build items from the right method (with TDD, one test = one item). For each step whose point is "confirm it works," add a paired proof-of-work evidence item (the screenshots, captured command output, or rendered diff that proves it) and an explicit human-review gate where that evidence is reviewed. On the PR, always place the agent's own review ahead of that gate. See Proof of Work for what good evidence is.
5. Make it live. Push the checklist into the agent's real todo surface (TodoWrite, a session todo list, or an open plan.md), keep exactly one item in progress, and rewrite the list on every state change. See Observable Progress for the discipline; the value is entirely in keeping it current.
6. Where the plan lives. The checklist lives in the live todo surface; the narrative plan lives in plan.md or an issue comment. Keep both current, and fold in anything the human adds mid-flight instead of tracking it loosely in chat.

The checklist template

Build the list around the full path to production, not just the code. A default spine, with evidence and a review gate; drop stages that do not apply, but start from the whole thing so nothing in the tail is forgotten:

Plan       ⬜ Confirm scope and acceptance criteria
           ⬜ Write the plan and this checklist
Build      ⬜ (feature work: one item per verifiable step)
           ⬜ Tests pass / typecheck / lint clean
PR-ready   ⬜ Code style + conventions (per repo standards)
           ⬜ Self-review the diff
           ⬜ Update docs / changelog
           ⬜ Proof of work: capture the evidence for the changed surfaces
Ship       ⬜ Open PR (Closes #N, or Part of #N if partial)
           ⬜ Review the PR: code-review + clear every automated/bot comment
           🔍 Review gate: human reviews the evidence, once the PR is clean
           ⬜ Address human review comments (one item per thread)
           ⬜ Merge
Deploy     ⬜ Watch CI / deploy to green
           ⬜ Verify in the deployed environment
Cleanup    ⬜ Delete branch + worktree
           ⬜ Close issue / update tracking

A 🔍 marks a human-review gate: a stop the agent does not cross on its own. That gate is where the proof-of-work evidence earns its keep, the reviewer inspects it and decides pass or fail before the change lands.

Never place the 🔍 PR-review gate before the agent has reviewed the PR itself and cleared the automated round. Earlier gates are unaffected: a plan-approval gate belongs up front, before any code exists. But on the PR, the agent reviews first, running code-review and then replying to every automated/bot/CI comment, so the human's first look lands on a clean PR. A checklist that prompts a human while machine findings or unanswered bot threads are still outstanding wastes the scarcest resource in the loop. Agent-review always precedes human-review on the PR; order the Ship items that way, every time.

Clearing the round means waiting for it, not sampling it. Bot reviews and CI runs still in flight have to finish before that item is done. Fetching only the comments that happen to exist yet lets a late finding land after the human has been prompted, which is the same failure with a delay on it.

Notes

• One list, one item in progress. Mark an item in progress when you start it, done the moment it is finished, then move on. A stale list is worse than none because it lies about progress.
• Carry it to the end. The plan is not done when the code is; it is done when the deploy is green and the branch and worktree are cleaned up.
• The plan is a contract the human can add to. When asked to fold in another step, add it to the list instead of tracking it in conversation.
• Evidence over assertion. Prefer a checkable proof (a test, captured output, a screenshot) to "done, it works" for any step whose point is that it works.
• Closes #N vs Part of #N. Use Closes #N only when the PR fully resolves the issue. For an umbrella or tracking issue with remaining sub-work, use Part of #N so merging does not auto-close it.

See also

• Living E2E Checklist: The discipline this topic applies, keeping one live checklist across the whole lifecycle.
• Proof of Work: Emit concrete, checkable evidence so a human can verify each "it works" step fast, on top of tests.
• Work Tracking: Persist this checklist and its history to the branch (a WORK.md per worktree) so any session can resume or hand off.
• Development Methods: TDD, refactoring, phased migrations, and root-cause diagnosis, the sources of good Build-stage items.
• Begin Work: Gather issue, branch, and PR context before planning delegated issue work.
• Pull Request Workflow: The Ship and Deploy stages this checklist ends in.
• Task List and Target Convergence Prompt: Structuring steps and defining the acceptance criteria the plan converges on.