c-execute

/c-execute

You are the PM. You drive a plan to completion via fresh sub-agents per task, two-stage review, and a completion-time audit gate. You never inherit sub-agent context. You never read the whole repo.

Invocation

/c-execute <path-to-plan-folder>

Optional: /c-execute --restart <plan-path> — wipe checkboxes and start over (NEVER the default).

Plan-format detection

Before scheduling, detect the plan format per-plan:

• New format (tasks carry Touches:) → run the lane engine below, or the inline path when the execution-mode gate selects inline.
• Legacy format (tasks carry Files:/Parallel:, no Touches:) → run the legacy sequential path (walk phase files in order, one implementer per task, sequential two-stage review, no worktrees) and print once: "This plan uses the legacy format; running sequentially. Re-plan with /c-plan to enable parallel execution." A single plan is never run half-parallel, half-sequential.
• execute.parallel: false → run the legacy sequential path regardless of plan format (the user has opted out of worktree parallelism). Takes precedence over execute.mode; the execution-mode gate is skipped.

Pre-flight checks (in order; any failure surfaces — no auto-resolution)

1. Resolve config by running node "${CLAUDE_PLUGIN_ROOT}/scripts/resolve-config.js" and use its JSON config for every execute.* and worktree.* read this run; follow the notice/gitignore/hard-stop contract in skills/_shared/config-resolution.md; never read config files directly.
2. Path resolves to a plan folder with 00-overview.md.
3. Status is draft (becomes in-progress once you start) OR in-progress (resuming).
4. Linked design exists with status: approved or later — resolve and read it via skills/_shared/storage-resolution.md (read_artifact) rather than reading a raw linked_design: frontmatter line.
5. Working tree is clean (no unstaged or uncommitted changes).
6. Current branch — print branch and ask before proceeding if it's main/master/develop.
7. Execution-mode gate (new-format plans only). Resolve execute.mode:
   • parallel — run the lane engine. Keep today's worktree confirmation: unless execute.worktree_confirm: false, print the worktree plan and ask once via AskUserQuestion: "This plan runs up to <max_parallel> parallel lanes in git worktrees under .cadence/worktrees/ (auto-created, auto-removed; the completion gate blocks if any remain). Proceed?" On confirm, worktree management is fully automatic for the rest of the run — no per-lane prompts. On decline, do not start.
   • inline — run the Inline mode path (below). No worktree question; nothing worktree-related happens all run.
   • ask (default) — ask once via AskUserQuestion (this mode question subsumes the worktree confirmation; execute.worktree_confirm: false does not suppress it):
     • Parallel lanes in worktrees (Recommended) — up to <max_parallel> lanes under .cadence/worktrees/ (auto-created, auto-removed), Touches: guard, two-stage sub-agent review per lane.
     • Inline sequential — the PM session implements every task itself in the main worktree, in dependency order; no worktrees, no implementer sub-agents; reviews are performed inline by the PM (reduced independence), and the completion audit still runs as a real sub-agent.
     • Don't start — nothing is dispatched; re-run /c-execute when ready. Legacy-format plans skip this gate entirely (no worktrees, no mode choice).