/c-execute

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

Purpose

Drives a draft plan to implemented code: your main session acts as project manager, dispatching a fresh worker per task, running every change through two reviews, and auditing the whole thing at the end, so you can trust the result without reading the diff yourself.

When to use it

Use /c-execute when a plan is written and you’re ready to build. It is the fourth stage, between plan and audit. Don’t use it to deploy or to validate a running system: it stops at implemented code.

Invocation forms

• /c-execute <path-to-plan-folder>: execute the plan.
• /c-execute --restart <plan-path>: wipe all checkboxes and start over (never the default; normal re-runs resume where they left off).

Inputs & preconditions

A plan folder with 00-overview.md at status draft (or in-progress to resume), a linked design that is approved or later, and a clean working tree. It prints the current branch and asks before proceeding if you’re on main/master/develop, and (for new-format plans) runs a one-time execution-mode gate: parallel lanes in worktrees (recommended) or inline sequential (every task implemented by the session itself — no worktrees, no implementer sub-agents; the completion audit still runs as a sub-agent). A concrete execute.mode value skips the question. It records the starting commit as base_sha on the first run so the audit can compute an exact diff range.

What it produces

Real code committed to the branch (one commit per task), every plan checkbox flipped to done, and (on a passing completion audit) the plan’s status flipped to implemented. Plan-file edits are committed once at the end.

Gates & guarantees

• Two-stage review on every change: a spec review and a code review, run at the same time. The spec decides what gets built; a code finding that contradicts it is kept for you to decide at the end instead of being dropped. For a task carrying visual citations, the spec review takes the design’s visual contract into its baseline, so a divergence from a named contract value is a spec gap like any other.
• The plan’s Global Constraints reach every implementer and both reviewers. For a decision plan, the spec review checks the plan’s decisions (names, files, tests and their assertions, the design’s values) and leaves how the code is written to the implementer and the code review; for a full-code plan it still expects an exact match. The style comes from the plan itself, never from config.
• Every implementer report that ran a step command quotes its real test output (the failing run before the change, the passing run after), and the spec reviewer checks it against what the plan said to expect. When a test misbehaves, the implementer tests one hypothesis at a time and stops after three failed attempts with an account of what it tried. When the plan itself is wrong it stops right away, and that reaches you as a plan question.
• Where the plan says nothing, the spec review judges the code by what a reasonable user would expect: a clear violation gets fixed, and an unclear case goes on an end-of-run list. The list (reviewer items plus the branch review’s non-Critical findings) lives in the plan overview, and you walk it once after the audit passes, accepting, fixing, or setting aside each item. Nothing a reviewer declines is dropped.
• Parallel work runs in isolated worktrees scheduled by each task’s dependencies, with a guard that serializes any two tasks touching the same files. Inline mode trades that machinery (and independent per-task review) for a single sequential session; the completion audit is unchanged in both modes.
• Merging a lane back (merge-on-land) acquires the shared merge lock, so cross-session merges into the same working branch (for example, a concurrent /c-worktree merge) serialize instead of colliding (gated by worktree.merge_lock).
• A completion audit must pass, and no end-of-run item may be left undecided, before the status can flip to implemented. The audit’s branch review reads the design and the whole branch on the most capable model; only a Critical finding blocks.
• On any block it surfaces three explicit paths (fix, mark out of scope, or abort) and never works around a blocker silently.
• It never auto-deploys, never amends commits, never skips commit hooks, and never reads the whole repo on every worker dispatch.

Related commands

• Previous: /c-plan produced the plan this command executes.
• Next: /c-audit is the standalone re-run of the same completion audit; then /c-validate once deployed.
• Deep dive: The Execute stage for the PM-and-sub-agent model and the two-stage review.