Implement from Plan

You are helping the user implement a plan. Plans live at <specs-dir>/<spec-name>/plans/<plan>.md and are produced by /spec-plan. Do NOT generate chunks yourself — the plan already defines the scope, checklist, and acceptance criteria.

Specs Folder Discovery

Run bun ~/.claude/tools/spec-edit/index.ts conf-get <cwd> where <cwd> is the current working directory. If it returns a path, use that as <specs-dir>. If it exits with no output, tell the user: "This project hasn't been set up yet — run /spec first to configure the specs folder."

No Arguments?

If invoked without arguments, run bun ~/.claude/tools/spec-edit/index.ts status <specs-dir> and present the output — it lists each spec's plans. Then ask: "Which plan do you want to implement?"

Using spec-edit for reading

Always use spec-edit to read specs/plans — it's faster than the Read tool:

bun ~/.claude/tools/spec-edit/index.ts status <specs-dir>         # Quick summary of specs + plans
bun ~/.claude/tools/spec-edit/index.ts read <file> [heading]      # Print file or section to stdout
bun ~/.claude/tools/spec-edit/index.ts list <file>                # List sections with line counts

Steps

1. Find the plan. The argument is a hint (e.g. "manifest versioning" backend). To find the plan:
   • Run status <specs-dir> to see all specs and their plans.
   • If the hint names a spec and the spec has exactly one matching plan, use it.
   • If multiple plans match, list them and ask the user to pick.
   • If no plans match, do NOT fall back to chunking a spec. Tell the user no matching plan was found and suggest running /spec-plan <spec-name> first. Stop.
2. Read the plan. Use spec-edit read on the plan file. The plan has these sections: Scope, Chunks (optional), Checklist, Todo, Open Questions.
3. Check Open Questions. If the plan has unresolved Open Questions, surface them and ask the user to resolve before implementing. Do not start coding with unresolved ambiguities.
4. Read the parent spec if needed. Only read ../spec.md if the plan references it and a decision isn't clear from the plan alone. Plans should be self-contained — if they aren't, flag it.

5. Propose investigation agents. Look at the Checklist and identify distinct areas of the existing codebase the plan will touch — existing interfaces, shared types, utilities, modules that will be extended or integrated with. For each distinct area, assess whether going in blind would risk incorrect assumptions or scope bleed.

   If two or more distinct areas would benefit from upfront exploration, propose spawning parallel investigation agents — one per area — before any code is written. Each agent's sole job is to read and understand the existing code in that area and report back: current patterns, relevant interfaces, naming conventions, anything the implementing agent needs to know to write consistent code without stepping on adjacent work.

   Present the proposed agents clearly: what each would investigate and what boundary they own. Then ask: "Want to run investigation agents first, or go straight to implementation?"

   Do not spawn agents here. Wait for the user's decision.

6. Analyze for parallel execution. Look at the plan's Chunks section (or, if absent, scan the Checklist for natural domain boundaries).

   For each candidate chunk, ask: can you name a clear owner — a distinct area of the codebase this agent would own exclusively? If investigation agents have already run, use their findings to sharpen the boundary definitions — shared types or interfaces that both agents touch should be explicitly flagged as read-only or assigned to one agent only.

   • If two or more independent chunks can be named clearly with unambiguous boundaries, propose the split. Show which chunks run in parallel, which must be sequential (and why), and what each agent would own.
   • If no clean ownership boundary exists, skip this step silently.

   Then ask: "Want to run this with multiple agents in parallel, or proceed sequentially?"

   Do not spawn agents here. Just present the proposed split and wait for the user's decision. If they choose parallel, they will orchestrate the spawning — or ask you to do it as a separate step.

7. Confirm scope. Summarize the Scope and Checklist back to the user in 3–6 bullets. Ask: "Ready to start?" Wait for approval before writing code.
8. Seed the Todo. If the Todo section is empty, derive a todo list from the Checklist (one entry per task-oriented item). Write it to the plan file using spec-edit replace <plan-file> "Todo". Use markdown checkboxes:

   - [ ] First task
   - [ ] Second task

9. Implement one todo at a time. For each unchecked todo:
   • Do the work. Follow the Checklist's key decisions.
   • Mark it done by updating the Todo section: rewrite it with spec-edit replace <plan-file> "Todo", flipping - [ ] → - [x] for the finished item.
   • Move to the next todo.
10. No commits, no status updates. Never commit. Do not update the spec. Only the Todo section of the plan is modified.
11. Verify the implementation. Once all todos are marked done, spawn a code-verifier agent to validate everything you touched. Pass it the list of affected files and projects. The agent must run whatever validation is appropriate for the project — static analysis, type checking, tests, builds, or any combination. It should report back with a clear pass/fail per check.

• If anything fails, read the verifier's output, fix the failures, and re-run the verifier.
• Do not report the implementation as complete until the verifier passes cleanly.

12. Stop when verified. Summarize what was built and point the user at the plan file for review.

Rules

• Stay within scope. Only implement what the Checklist says.
• If you discover the plan is wrong or incomplete, stop and flag it — don't silently deviate. The user may want to update the plan (via /spec plan or direct edit) before continuing.
• If the plan is ambiguous on an implementation detail, ask — don't guess. Add it to Open Questions if it needs to be captured.
• Follow the conventions and patterns established in the project.
• Never break out of the plan to do "related" cleanup work. That's a separate plan.

$ARGUMENTS