Execution — Execute Plans at Scale

SkillProductivity

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.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Execution — Execute Plans at Scale skill

What this skill tells your AI

The instructions your AI receives, as published by tody-agent/codymaster in skills/cm-execution/SKILL.md and read by ahel’s review.

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)
ModeOne-line summaryLoad
ABatch 3 tasks, report, then continuereferences/mode-a-batch.md
BFresh subagent per task + 2-stage reviewreferences/mode-b-subagent.md
COne agent per independent problem domainreferences/mode-c-parallel.md
DReason → Act → Reflect → Verify loopreferences/mode-d-rarv.md
EDependency-aware parallel + per-agent quality gatereferences/mode-e-triz-parallel.md
FSingle agent rotates Architect → Engineer → Reviewerreferences/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

SkillWhen
cm-planningProduces the plan this skill consumes
cm-tddUse per task when implementing or fixing
cm-quality-gateVERIFY phase / pre-report validation
cm-code-reviewFinal review after all tasks are done
cm-design-systemRecommended before frontend-heavy tasks

Workflows

CommandPurpose
/cm-startCreate tasks + launch RARV + open dashboard
/cm-statusQuick terminal progress summary
/cm-dashboardOpen browser dashboard

The Bottom Line

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

Signals

GitHub stars
52
Forks
23
Last commit
Aug 2026
Advanced
Catalog kind
skill
Gateway key
cm-execution
Source
github.com/tody-agent/codymaster