---

name: cm-execution description: Use when executing approved implementation plans. Routes to 1 of 6 execution modes (batch/subagent/parallel/RARV/TRIZ/party) based on task shape. Loads detail refs on-demand. token_budget: 1800 token_core: 450 token_refs: mode-a-batch: 280 mode-b-subagent: 380 mode-c-parallel: 240 mode-d-rarv: 520 mode-e-triz-parallel: 460 mode-f-party: 420 persona-dispatch: 180 security-rules: 540 compressed: true deprecated: false

Execution — Execute Plans at Scale

TL;DR

• Use when running an approved plan from cm-planning
• Reads handoff/plan.json or openspec/changes/[name]/tasks.md
• Writes handoff/exec.json
• Autonomy: one scoped authorization, no step/batch re-approval
• Always verify before reporting done
• Next cm-code-review

Role: Lead Developer. You execute plans systematically with continuous verification and non-blocking status updates.

Follow _shared/autonomy-policy.md. Treat an approved plan as scoped execution authorization through verification. Do not request per-step or per-batch re-approval inside that scope.

Step 0: Load Working Memory (MANDATORY)

Per _shared/helpers.md#Load-Working-Memory. After EACH completed task: _shared/helpers.md#Update-Continuity.

Step 1: Pre-flight Skill Coverage Audit

Scan plan tasks for tech keywords, cross-reference cm-skill-index, check installed skills, and use npx skills find when the plan reaches beyond current coverage. If codegraph or cm-codeintell context is available, inject it into agent prompts so execution skips redundant repo searching.

Confirm the authorization state from the handoff, not by asking the user again:

• Approved plan → execute its stated scope through verification.
• Clear, reversible micro task directly requested by the user → proceed with zero approval.
• Meaningful change without an approved plan → present a concise plan and request one approval at the plan-to-execution boundary.
• Material scope change or sensitive action → pause under the shared policy; execution-mode selection itself never needs approval.

Step 2: Choose Mode

Have an approved plan?
├─ Have 2+ independent tasks where parallel execution helps?
│   ├─ File/dependency analysis and conflict pre-flight pass?
│   │   └─ YES → Mode E (TRIZ-Parallel) ★ recommended
│   └─ Tasks are ordered/dependent and isolated subagents are available?
│       └─ YES → Mode B (Subagent-Driven)
├─ One non-trivial task, want multi-perspective without subagent cost?
│   └─ YES → Mode F (Party, persona rotation)
├─ Multiple independent failures across subsystems?
│   └─ YES → Mode C (Parallel Dispatch)
├─ Autonomous loop with backlog (`/cm-start` flow)?
│   └─ YES → Mode D (RARV)
└─ Otherwise
    └─ Mode A (Batch Execution)

| Mode | One-line summary | Load | |---|---|---| | A | Batch 3 tasks, report, then continue | references/mode-a-batch.md | | B | Fresh subagent per task + 2-stage review | references/mode-b-subagent.md | | C | One agent per independent problem domain | references/mode-c-parallel.md | | D | Reason → Act → Reflect → Verify loop | references/mode-d-rarv.md | | E | Dependency-aware parallel + per-agent quality gate | references/mode-e-triz-parallel.md | | F | Single agent rotates Architect → Engineer → Reviewer | references/mode-f-party.md |

Action: Pick exactly one mode, read only that reference, and execute from there.

Before selecting Mode B, verify the harness supports fresh and resumable isolated sessions. If it does not, route to Mode F (reduced review independence) or Mode A; never silently simulate independent reviewers in one context. Mode B is serial. Mode E remains the only mode for independent parallel tasks and always retains conflict pre-flight.

Conditional References

• Mode B / E / F → also read references/persona-dispatch.md
• Task touches auth, files, subprocess, DOM, config paths, or user input → MUST read references/security-rules.md before writing code

Karpathy Discipline — Surgical Changes

• Touch only what the task requires. No "while I'm here" refactors.
• Match existing style even if you would write it differently.
• Notice unrelated dead code? Mention it, do not delete it.
• Clean only your own orphans. Pre-existing dead code stays unless asked.
• Diff test: every changed line must trace to the task.
• After a task or batch, send a non-blocking status update and continue while scoped execution authorization remains valid.

Integration

| Skill | When | |---|---| | cm-planning | Produces the plan this skill consumes | | cm-tdd | Use per task when implementing or fixing | | cm-quality-gate | VERIFY phase / pre-report validation | | cm-code-review | Final review after all tasks are done | | cm-design-system | Recommended before frontend-heavy tasks |

Workflows

| Command | Purpose | |---|---| | /cm-start | Create tasks + launch RARV + open dashboard | | /cm-status | Quick terminal progress summary | | /cm-dashboard | Open browser dashboard |

The Bottom Line

Choose your mode → load that one reference → execute the authorized scope → verify → review.