/c-plan

Source of truth: skills/c-plan/SKILL.md. For the why behind this stage, read the Plan deep dive.

Purpose

Translates an approved design into an AI-readable plan folder (exact file paths, exact commands, no narrative, and either the full code or the exact decisions the code must honor, per plan.style) so the work can be executed step by step.

When to use it

Use /c-plan once a design is approved and you want a precise, executable blueprint before building. It is the third stage, between design and execute. Don’t use it to write code or to run anything: it only writes the plan.

Invocation forms

• /c-plan: reads the approved design with the matching slug and writes the plan folder.

One design always becomes exactly one plan; large work is split into phase docs inside that single plan, not into sibling plans. After reading the design, it confirms the phase decomposition with you.

It then asks one generation-mode question: all-at-once (the default — parallel generator sub-agents plus a consistency sweep) or inline (the main session writes every doc itself; no sub-agents, no sweep). A concrete authoring.plan_mode value skips the question.

With plan.style: ask it also asks which style to write: full-code (the default; every code step shows the code) or decisions (each step records the exact signature, the test and its assertions, and the design’s values, and the implementer writes the code).

For every plan, in the same exchange as the phase decomposition, it confirms the plan’s Global Constraints: project-wide rules it extracted from the design, CLAUDE.md, and the repo’s manifests.

Inputs & preconditions

A design whose 00-overview.md has status: approved. When the design carries a 95-visual-contract slot, the read includes that doc and the frozen mockup version it names.

It refuses if the design is still draft or in-review (finish and approve it first), if a plan folder with the same slug already exists at a non-draft status (it won’t overwrite), or if the design has a 95 slot whose freeze record still reads frozen: none. That last case is a malformed approved design: approval is what stamps the freeze, so an unstamped one means the approval step didn’t complete, and the fix is back in /c-design.

What it produces

A plan folder at <paths.plans>/{yyyy-mm-dd-slug}/: a 00-overview.md (goal, architecture, a Plan style: line, design link, a Global Constraints section, a Review Focus section (up to five inputs the design implies but no test covers, each pinned by a check in the task that owns the code), plan index, file map, plus a Surface map for a design with a 95 slot, naming the concrete files that implement each governed surface), one or more execution-ordered phase docs (01-…, 02-…) with fully-specified tasks (in a decision plan each task also carries an Interfaces block naming what it uses from and provides to other tasks), a 96-validation.md, shell 97/98 docs pointing back to the design, and a 99-out-of-scope.md. It also writes linked_design: onto the new plan and linked_plan: (singular) onto the design.

Gates & guarantees

• Every file path, line range, symbol, and import the plan cites is ground-truthed against the real code before it lands.
• Every task carries Reads:, Touches:, and Depends: fields and ends with a commit step; banned placeholder phrases (TBD, TODO, “handle edge cases”, “similar to Task N”) are blocked in self-review.
• For a design with a 95 slot, every task whose Touches: intersects the Surface map gets the visual contract and a mockup:NN citation appended to its Reads: automatically, and self-review checks that the attachment is complete and hasn’t leaked onto tasks outside the map. There is no new task field: Reads: already carries the read-before-writing contract.
• Each plan states its style in its overview, and execution reads it from there, never from config, so changing plan.style never affects a plan already written. A plan with no style line runs as full-code.
• Decision plans pass an interface-closure check (every name a task borrows has a source). Self-review also reports the plan’s length against the design and its code share as advisory signals; it rewrites only steps that spell out a body the signature and tests already determine. Every plan’s Global Constraints trace to a source, and every Review Focus entry has its pin in the task it names.
• The closing summary lists every self-review check that applies, by number, with its result (clean, fixed, or flagged). A check missing from the list didn’t run.
• It never writes code, never runs anything, and never auto-executes; /c-execute is invoked separately.

Related commands

• Previous: /c-design produced the design this plan is built from.
• Next: /c-execute drives this plan to implemented code.
• Deep dive: The Plan stage for why a separate, exact plan exists, the two plan styles, and the linkage mechanism.