| name | exec_plan |
| description | Executes an implementation plan created by the make_plan skill. Use when the user says "exec_plan", "run the plan", "execute the plan", "implement the plan in plans/<feature>", or "continue the plan for <feature>". Accepts a feature name and an optional commit-mode flag: --ask-commit (default, ask after each verified task), --no-commit (never commit), or --auto-commit (commit + push after each verified task). Reads plans/<feature>/99-execution-plan.md, finds the next incomplete task, and runs the per-task loop (implement -> update the execution plan immediately -> verify -> commit per mode) following specification-first task ordering. When the repo's CLAUDE.md carries a CodeOps quality-profile block, a profile-gated quality loop reviews each executed phase (reviewer + auditor agents); critical/major findings pause for a user ruling in every commit mode. |
| when_to_use | Use for plan EXECUTION only. Plan CREATION lives in the make_plan skill — point the user there instead of duplicating it. Trigger on /exec_plan or any request to run, execute, implement, or continue an existing plan under plans/<feature>/. |
| argument-hint | [feature-name] [--ask-commit | --no-commit | --auto-commit] |
| arguments | feature |
exec_plan — Execute an Implementation Plan
CodeOps Skills Version: 3.11.0
Execute the implementation plan at plans/$ARGUMENTS/99-execution-plan.md. The first
argument is the feature name; an optional flag selects the commit mode.
This skill covers execution only. To create a plan, use the make_plan skill.
Resolve the plan path first (layout-aware)
Determine the layout via ../../_shared/layout-convention.md:
- Flat layout (no marker): the plan is at
plans/$ARGUMENTS/99-execution-plan.md — as flat layout always has.
- Nested layout (marker present): the plan is under a feature —
codeops/features/<f>/plans/<plan>/99-execution-plan.md. If the target feature/plan is ambiguous,
ask the user (never guess). A non-trivial task mini-plan lives at the same nested path and
executes identically (see "Lightweight tasks" above). Everywhere below that says
plans/$ARGUMENTS/ means this resolved plan path.
Commit modes
| Flag | Behavior |
|---|
(none) / --ask-commit | Default. After each verified task, ask the user whether to commit. |
--no-commit | Never commit, never ask. Pure implementation. |
--auto-commit | Automatically commit + push (via /gitcmp) after each verified task. |
Full prompt wording, end-of-plan reminders, and commit-message format live in
commit-modes.md — read it before the first commit decision.
Lightweight tasks (both layouts)
A non-trivial task has a single mini-plan at the resolved task path (flat:
plans/<task-slug>/99-execution-plan.md; nested:
codeops/features/<f>/plans/<task-slug>/99-execution-plan.md). Execute it exactly like a feature
plan — same per-task loop, same real-time update mandate, same commit modes — it is just a
smaller 99-execution-plan.md (objective + checklist + verify, no 00–07 set). Specification-first
ordering still applies when the task warrants tests (e.g. a bugfix's regression test).
A trivial task has no plan document to run: do the work directly, then record it as a
T-NN roadmap row + the commit (no execution-plan loop). The task model and routing rule live in
../../_shared/layout-convention.md — the lane exists in both
layouts (flat gained it in 3.2.0).
Execution mode — inline first
Phases run inline on the session model by default; a phase is dispatched as ONE pinned-model
executor only when its routing tag maps to a cheaper model AND the phase amortizes the executor
bootstrap. Per-task or parallel dispatch happens only on the user's explicit request (it costs
more tokens, not fewer). Full rules in execution-protocol.md.
Execution protocol (summary)
Read execution-protocol.md for the full step-by-step protocol,
the specification-first ordering rules, the real-time update mandate, and the session
summary template. The essentials:
Step 1 — Load the plan
- Read
plans/$ARGUMENTS/99-execution-plan.md.
- Find incomplete tasks — both
[ ] and implemented-but-unverified [~]; read supporting specs
in plans/$ARGUMENTS/.
- Determine the starting point: a
[~] task is resumed first (re-verify, then promote or keep
fixing); otherwise the first [ ] task.
- If the plan is missing/empty/already complete, STOP — see the load table in
execution-protocol.md. Generally suggest the make_plan skill.
Version check: look for > **CodeOps Version**: X.Y.Z (or CodeOps Skills Version) in
00-index.md / 99-execution-plan.md. If it is older than 3.0.0 or missing, suggest the
upgrade_plan skill, then ask whether to proceed anyway. Suggestion only — the user may proceed.
Step 2 — Execute tasks (per-task loop)
For each task, in order:
- Implement the task following the technical specs in
plans/$ARGUMENTS/.
- 🚨 Immediately update
99-execution-plan.md — completion marks are two-stage: mark the
task [~] with an implemented-timestamp in its phase task list (or, in a pre-3.3.0 plan, in
the Master Progress Checklist — see the protocol's dual-format detection) and bump the Progress
counter / Last Updated stamp as soon as implementation finishes (crash-safe), promote it to
[x] only after its verification passes. A task never shows [x] with a failing verify.
- Verify — run your project's verify command (from the project's CLAUDE.md, or detected
project conventions), output captured per the protocol's Verify-output capture rule
(PASS one-liner; on failure the last 50 log lines + log path). Pass → promote
[~] → [x];
fail → fix and re-verify (mark stays [~]).
- Commit per the active commit mode (see commit-modes.md) — the commit
gate keys off
[x].
- Techdocs check (after each phase): if the phase introduced architectural changes and
techdocs exist, do an incremental update via the techdocs skill.
- Continue until all tasks are complete. (Claude Code auto-compacts context — no manual
threshold handling is needed.)
🚨 Specification-first task ordering — non-negotiable. Within each feature:
spec tests → verify red → implement → verify green → impl tests → full verify.
Never write implementation code before its spec tests exist, and never edit a spec test to
match the implementation (the implementation is wrong, not the test). Details and the
compressed single-session form are in execution-protocol.md.
🚨 Zero-ambiguity during execution. If you hit any detail not covered by the plan docs or
00-ambiguity-register.md, STOP, present options to the user, wait for an explicit decision,
record it in 00-ambiguity-register.md (tag (runtime)), then resume. Never guess.
Grounded Options & Recommendations (coding standards → Working style) apply here. Before presenting options/findings/recommendations: filter out non-viable ones (no strawmen; ≥2 only when ≥2 are genuinely viable, else present the single viable path and name what was rejected), second-guess each, verify any code-modifying option against the actual current code (cite file:line), and lead with a recommendation backed by grounded reasoning. Match ceremony to stakes — the user decides. Apply the recommendation-hardening protocol (_shared/recommendation-hardening.md) to consequential recommendations; escalate to an independent challenger only when the decision is genuinely high-stakes.
Step 3 — Session wrap-up
- Finish the current task before stopping.
- 🚨 First, update
99-execution-plan.md with all completed tasks (before anything else).
- Run the verify command.
- Handle the commit per the active commit mode.
- Report a session summary (must state
Execution Plan Updated: ✅). Template in
execution-protocol.md.
To resume in a later session, just run /exec_plan $ARGUMENTS again — the execution plan is the
source of truth and tells the skill where to pick up.
Quality loop (profile-gated)
When the repo's CLAUDE.md carries a quality-profile block, every executed phase (and task
mini-plan) ends with a post-phase quality review; without the block this loop is fully
dormant. Activation rules, lenses, supersession, dispatch packets, and budget caps are defined
once in ../../_shared/quality-profile.md — this skill
links to them, never restates them.
The flow: the protocol records a phase-start ref when the phase begins; after the phase's last
task verifies, the phase-reviewer and any active auditors are dispatched in parallel on the
phase diff, their findings are merged and presented in severity-grouped batches, and each ruling
is emitted to telemetry.
🚨 Finding gate (load-bearing). 🔴 CRITICAL and 🟠 MAJOR findings PAUSE execution for the
user's ruling in ALL commit modes — auto-commit never bypasses the pause. 🟡 MINOR findings are
report-only. Accepted fixes are implemented, verified, follow-up-committed per the commit mode,
and (after 🔴/🟠 fixes) re-reviewed ONCE on the fix diff — never a third time.
Step-by-step mechanics — the phase-start ref, spec-author dispatch, the post-phase quality step,
and emission points — live in execution-protocol.md.
Roadmap sync
If a roadmap exists (plans/00-roadmap.md flat, or the feature's
codeops/features/<f>/00-roadmap.md nested), keep it in sync via the roadmap skill (update-first,
before verify/commit/next): set the RD/task row to Executing (🔄) on start, Done (✅) on
completion, and Blocked (⛔) with a nested ↳ DEF-n sub-row when a blocking dependency is
discovered. Nested layout: after each per-feature transition, cascade to the portfolio
codeops/00-roadmap.md (re-roll that feature's row) before proceeding — per the roadmap skill's
cascade mandate. If no roadmap exists, these hooks are inert.
Error handling
Brief rules for verification failure, plan deviation, and mid-task interruption are in
execution-protocol.md — consult it when something goes wrong.
Post-completion hooks (all tasks done)
- Handle the end-of-plan commit per the active commit mode (see commit-modes.md).
- Techdocs: if techdocs exist, do a comprehensive update via the techdocs skill; otherwise
ask whether to create them.
- Re-analyze: ask whether to re-analyze the project and update the project's CLAUDE.md via
the
/analyze_project command.
- Roadmap: set the RD row to
Done via the roadmap skill if a roadmap exists.
Conventions
- Follow your project's coding and testing standards (the project's CLAUDE.md, or detected
project conventions). If no CLAUDE.md exists, detect build/test/verify commands from manifest
files and use only facts you can read — do not invent settings.
- Commit using
/gitcm (commit only) or /gitcmp (commit + push), or a normal git commit.
- Related skills: make_plan (creation), upgrade_plan (outdated plans), preflight, roadmap, techdocs.
