ring-executing-plans

name: ring:executing-plans description: "Executing a phased plan from ring:writing-plans in rolling waves: the main agent supervises, dispatching one workflow per wave-unit (phase or epic — user's choice) that implements its tasks with TDD and signed commits via ring:committing-changes, reviews the returned work, checkpoints with the user, then elaborates the next phase against the real landed code. Use when a phased plan exists and you want session-supervised execution with a human reviewing each wave. Skip when no plan exists (use ring:writing-plans) or the full gated specialist + reviewer pool is wanted (use ring:running-dev-cycle)."

Executing Plans

When to use

• A phased plan exists (typically produced by ring:writing-plans)
• You want to supervise execution from this session — review each dispatched wave, checkpoint between phases — rather than hand off to the full gated dev cycle
• Work benefits from phase checkpoints and course-correction between phases

Skip when

• Plan doesn't exist yet — use ring:writing-plans first
• Production-grade work requiring the full review pool — use ring:running-dev-cycle instead (lean backend cycle, Gate 0/8/9, dispatches specialists in parallel)
• Plan covers multiple independent subsystems — split into separate plans before executing

Sequence

Runs after: ring:writing-plans (consumes and updates its plan document) Alternative: ring:running-dev-cycle (subagent-orchestrated, gated workflow with parallel specialist dispatch)

Related

Companion skills: ring:writing-plans (defines the Epic and Task formats used during elaboration), ring:test-driven-development (enforces RED→GREEN→REFACTOR per task), ring:committing-changes (closes each task with a signed atomic commit)

The loop: dispatch the current wave as a workflow → review the returned work → phase checkpoint → elaborate the next phase against the real landed code → dispatch the next wave → repeat. The main agent stays the supervisor and reviewer; the dispatched workflow does the task-by-task implementation. The plan document is the living source of truth — elaboration writes tasks back into it.

Announce at start: "Using ring:executing-plans to implement this plan."

The Process

Step 1: Load and Review Plan

1. Read the plan file end-to-end
2. Verify the header (Goal, Architecture, Tech Stack, Phase Overview) is present
3. Verify exactly one phase is task-detailed (the current wave); later phases sit at epic level
4. Review critically — raise concerns with the user before starting

Then choose dispatch granularity. Ask the user — using the question/ask tool the harness provides (e.g. AskUserQuestion in Claude Code) — whether to dispatch one workflow per phase (the whole phase runs as a single wave) or one workflow per epic (finer-grained: the main agent reviews and course-corrects between epics inside a phase). Default to per-phase if the user skips. This sets the wave-unit for the rest of execution.

Step 2: Dispatch and Supervise the Current Wave

Dispatch the wave-unit chosen in Step 1 — a whole phase, or a single epic — as one workflow covering all its tasks. The main agent does not implement; it supervises and reviews.

The dispatched workflow runs each task in the unit, in dependency order, and for every task MUST:

1. Implement per the task's Implementation vision — its decisions are binding; raise a blocker rather than silently diverging
2. Use ring:test-driven-development for new production code: write the failing test first from the task's Verification intent, capture the RED output, then implement
3. Run the task's verification; capture the output
4. Close the task with ring:committing-changes (atomic, signed)
5. Tick the task's - [ ] Done checkbox in the plan document only after verification passes

Do not skip the RED phase. The plan carries no test code — the failing test comes from the verification intent.

When the workflow returns, the main agent reviews the wave as supervisor: confirm each task's tests actually ran and passed, commits are atomic and signed, the implementation matches the vision, and nothing was silently deferred. Bounce anything that fails review into a follow-up dispatch before moving on. If the wave-unit is an epic and the phase has more epics, dispatch the next epic; advance to the checkpoint only once the phase has no tasks left.

Step 3: Phase Checkpoint (user gate)

When every task in the phase is complete and verified:

1. Update the plan document: flip the phase's Status to Complete in the Phase Overview; record any deviations from the plan that affect later phases
2. Present to the user: what was built, test results, deviations and why
3. STOP and wait for the user's check before elaborating the next phase — unless the user pre-authorized continuous execution, in which case state that and proceed

Step 4: Elaborate the Next Phase (rolling wave)

After the checkpoint, detail the next phase before implementing it:

1. Re-read the phase's epics against the codebase as it now exists — not as the plan assumed it would
2. Fold in learnings and deviations from completed phases; if reality diverged enough to change an epic's scope or approach, surface that to the user before proceeding
3. Break each epic into dispatch-ready tasks using the Task Format from ring:writing-plans (load that skill if the format is not in context) — same bar: context with file:line references, implementation vision with decisions made, exact files, verification, done-when
4. Write the tasks into the plan document under their epics; flip the phase's Status to Detailed
5. Return to Step 2 — dispatch the newly detailed wave (per the granularity chosen in Step 1) and await its return

Repeat Steps 2–4 until every phase is complete.

Step 5: Complete Development

After all phases complete and verified:

• Announce: "All phases complete and verified. Closing with ring:committing-changes."
• Use ring:committing-changes for the final commit if uncommitted work remains
• Offer to push: git push (or git push -u origin <branch> if no upstream)

For production work, hand off to ring:reviewing-code to run the review pool against the cumulative diff.

⛔ When to Stop and Ask

Stop executing immediately when:

Ask for clarification rather than guessing. Plan execution is not the place for taste calls.

⛔ Branch Safety

MUST NOT start implementation on main/master without explicit user consent. If currently on a protected branch:

1. Stop
2. Ask the user to create or switch to a feature branch (or invoke ring:creating-worktrees for an isolated workspace)
3. Resume only after branch confirmation

Remember

• Review the plan critically first — fix gaps before executing
• Choose dispatch granularity up front — one workflow per phase, or one per epic
• The main agent supervises and reviews; the dispatched workflow implements
• One detailed wave at a time — never elaborate two phases ahead
• The plan document is living: tick tasks, flip statuses, record deviations
• Don't skip verifications (RED phase included)
• Phase checkpoint is a user gate, not a formality
• Elaborate against the codebase as it exists, not as the plan assumed
• Stop when blocked — don't guess
• Never implement on main/master without consent

Verification Checklist

Before marking the plan complete:

• Dispatch granularity (phase or epic) chosen with the user
• Every dispatched wave reviewed by the main agent before its checkpoint
• Every phase implemented and verified, in order
• Every phase boundary checkpointed with the user (or continuous mode explicitly pre-authorized)
• Every later phase elaborated into tasks before implementation, against the real codebase
• Every RED phase produced a real failure (output captured)
• Every task closed with an atomic, signed commit via ring:committing-changes
• Plan document reflects final state (statuses, ticked tasks, recorded deviations)
• Working tree clean (or remaining changes documented)
• Final commit / push offered to user