ring-executing-plans

name	ring:executing-plans
description	Inline execution of an implementation plan task-by-task with review checkpoints. Loads a written plan, reviews it critically, executes tasks in order with verification, and hands off to finishing skills when done.

Executing Plans

When to use

• A written plan exists (typically produced by ring:writing-plans)
• Inline execution in this session is preferred over full subagent orchestration
• Plan is small-to-medium and benefits from fast iteration with checkpoints

Skip when

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

Sequence

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

Related

Companion skills: ring:test-driven-development (enforces RED→GREEN→REFACTOR per task), ring:commit (closes each task with a signed atomic commit)

---

Load the plan. Review it critically. Execute every task in order. Stop and ask when blocked.

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. Review critically — identify questions or concerns
3. Verify the plan header (Goal, Architecture, Tech Stack) is present
4. If concerns: raise them with the user before starting
5. If no concerns: create the task tracker and proceed

Concern type	Action
Placeholder content ("TBD", "appropriate error handling")	Block; ask user to refine plan or fill in
Missing/contradictory test commands	Block; ask user to clarify
Type/method name inconsistency across tasks	Block; ask user to reconcile
Stylistic / "nice to have"	Note but proceed

Step 2: Execute Tasks

For each task in the plan:

1. Mark as in-progress in the task tracker
2. Follow each step exactly — the plan has bite-sized steps for a reason
3. Run verifications as specified (test commands, expected output)
4. Use ring:test-driven-development when a step writes new production code
5. Use ring:commit at the step that says "Commit"
6. Mark as completed only after verification passes

Do not skip the RED phase. If the plan says "Run test to verify it fails," run it and paste the failure output. Skipping verification means the plan didn't actually execute.

Step 3: Complete Development

After all tasks complete and verified:

• Announce: "All tasks complete and verified. Closing with ring:commit."
• Use ring:commit 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:codereview to run the review pool against the cumulative diff.

⛔ When to Stop and Ask

Stop executing immediately when:

Trigger	Why it blocks
Missing dependency	Can't proceed reliably without it
Test fails unexpectedly (not RED phase)	Either plan is wrong or implementation diverged
Instruction unclear or ambiguous	Guessing wastes more time than asking
Verification fails repeatedly	Underlying issue, not a flakiness retry
Plan has critical gaps preventing start	Should have been caught in Step 1; refine before continuing

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

When to Revisit Earlier Steps

Return to Step 1 (Review) when:

• User updates the plan based on your feedback
• Fundamental approach needs rethinking mid-execution

Don't force through blockers — stop and ask. A correctly-executed wrong plan still produces wrong code.

⛔ 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:worktree for an isolated workspace)
3. Resume only after branch confirmation

Remember

• Review plan critically first — fix gaps before executing
• Follow plan steps exactly — they are bite-sized for a reason
• Don't skip verifications (RED phase included)
• Reference required skills when the plan says to (ring:test-driven-development, ring:commit)
• Stop when blocked — don't guess
• Never implement on main/master without consent

Verification Checklist

Before marking the plan complete:

• Every task in the plan executed and verified
• Every RED phase produced a real failure (output captured)
• Every GREEN phase passes with minimal code
• Every "Commit" step produced an atomic, signed commit via ring:commit
• Working tree clean (or remaining changes documented)
• Final commit / push offered to user