What is executing-plans?

This Claude skill facilitates structured and controlled plan execution for complex development and technical tasks. It bridges the gap between planning and implementation by offering two distinct modes: fully autonomous 'one-go' execution for speed, and batch-based execution with mandatory human review checkpoints for high-stakes projects. By integrating automated code reviews and multi-agent dispatching, it ensures that every step of a project plan is executed accurately, verified, and aligned with user expectations, significantly reducing the risk of architectural drift or unvetted changes.

When should I use executing-plans?

executing-plans is useful in the following scenarios: • Complex Feature Implementation: Systematically execute multi-step development plans where each backend and frontend component requires verification before moving to the next phase. • High-Stakes Refactoring: Safely manage large-scale code changes by using batch mode to review architectural impacts and code quality at every critical checkpoint. • Autonomous Development: Accelerate routine coding tasks by switching to 'one-go' mode, allowing the agent to handle implementation and internal code reviews independently until completion. • Cross-Functional Orchestration: Coordinate specialized agents (e.g., Go backend, TypeScript frontend, DevOps) to work on a unified plan with centralized progress tracking and mandatory quality gates.

name	ring:executing-plans
description	\|
trigger	\|
skip_when	\|
- Same session with independent tasks → use ring	subagent-driven-development
- No plan exists → use ring	writing-plans first
- Plan needs revision → use ring	brainstorming first
after	[ring:writing-plans, ring:pre-dev-task-breakdown]
similar	[ring:subagent-driven-development]

Executing Plans

Overview

Load plan, review critically, choose execution mode, execute tasks with code review.

Core principle: User chooses between autonomous execution or batch execution with human review checkpoints.

Two execution modes:

One-go (autonomous): Execute all batches continuously with code review, report only at completion
Batch (with review): Execute one batch, code review, pause for human feedback, repeat

Announce at start: "I'm using the ring:executing-plans skill to implement this plan."

The Process

Step 1: Load and Review Plan

Read plan file
Review critically - identify any questions or concerns about the plan
If concerns: Raise them with your human partner before starting
If no concerns: Create TodoWrite and proceed to Step 2

Step 2: Choose Execution Mode (MANDATORY)

⚠️ THIS STEP IS NON-NEGOTIABLE. You MUST use AskUserQuestion before executing ANY tasks.

Ask: "How would you like to execute this plan?" Options: (1) One-go (autonomous) - all batches with code review, no human review until completion (2) Batch (with review) - pause for human review after each batch

Based on response: One-go → Steps 3-4 loop until done | Batch → Steps 3-5 loop

Why AskUserQuestion is Mandatory (Not "Contextual Guidance")

This is a structural checkpoint, not optional UX polish.

User saying "don't wait", "don't ask questions", or "just execute" does NOT skip this step because:

Execution mode affects architecture - One-go vs batch determines review checkpoints, error recovery paths, and rollback points
Implicit intent ≠ explicit choice - "Don't wait" might mean "use one-go" OR "ask quickly and proceed"
AskUserQuestion takes 3 seconds - It's not an interruption, it's a confirmation
Emergency pressure is exactly when mistakes happen - Structural gates exist FOR high-pressure moments

Common Rationalizations That Mean You're About to Violate This Rule:

Rationalization	Reality
"User intent is crystal clear"	Intent is not the same as explicit selection. Ask anyway.
"This is contextual guidance, not absolute law"	Wrong. It says MANDATORY. That means mandatory.
"Asking would violate their 'don't ask' instruction"	AskUserQuestion is a 3-second structural gate, not a conversation.
"Skills are tools, not bureaucratic checklists"	This skill IS the checklist. Follow it.
"Interpreting spirit over letter"	The spirit IS the letter. Use AskUserQuestion.
"User already chose by saying 'just execute'"	Verbal shorthand ≠ structured mode selection. Ask.

If you catch yourself thinking any of these → STOP → Use AskUserQuestion anyway.

Step 3: Execute Batch

Default: First 3 tasks

For each task: Mark in_progress → Dispatch to agent → Follow plan steps exactly → Run verifications → Mark completed

Step 4: Run Code Review

After each batch, REQUIRED: Use ring:requesting-code-review (all 3 reviewers in parallel)

Handle by severity:

Critical/High/Medium: Fix immediately (no TODO) → re-run all 3 reviewers → repeat until resolved
Low: Add TODO(review): [Issue] ([reviewer], [date], Low)
Cosmetic: Add FIXME(nitpick): [Issue] ([reviewer], [date], Cosmetic)

Proceed when: Zero Critical/High/Medium remain + all Low/Cosmetic have comments

Step 5: Report and Continue

One-go mode: Log internally → proceed to next batch → report only at completion Batch mode: Show implementation + verification + review results → "Ready for feedback." → wait → apply changes → proceed

Step 6: Complete Development

Use finishing-a-development-branch to verify tests, present options, execute choice.

When to Stop

STOP immediately: Blocker mid-batch | Critical gaps | Unclear instruction | Verification fails repeatedly. Ask rather than guess.

Remember

MANDATORY: AskUserQuestion for execution mode - NO exceptions
Use * agents over general-purpose when available
Run code review after each batch (all 3 parallel)
Fix Critical/High/Medium immediately (no TODO)
Low → TODO, Cosmetic → FIXME
Stop when blocked, don't guess
If rationalizing why to skip AskUserQuestion → You're wrong → Ask anyway

executing-plans

When & Why to Use This Skill

Use Cases