/executing-plans
Controlled plan execution with human review checkpoints - loads plan, executes in batches, pauses for feedback. Supports one-go (autonomous) or batch modes.
$ npx -y skills add LerianStudio/ring --skill executing-plans --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/executing-plans
Context preview
The summary Claude sees to decide when to auto-load this skill.
Controlled plan execution with human review checkpoints - loads plan, executes in batches, pauses for feedback. Supports one-go (autonomous) or batch modes.
SKILL.md
executing-plans.SKILL.mdname: ring:executing-plans
description: |
Controlled plan execution with human review checkpoints - loads plan, executes
in batches, pauses for feedback. Supports one-go (autonomous) or batch modes.
trigger: |
- Have a plan file ready to execute
- Want human review between task batches
- Need structured checkpoints during implementation
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
sequence:
after: [ring:writing-plans, ring:pre-dev-task-breakdown]
related:
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
1. Read plan file 2. Review critically - identify any questions or concerns about the plan 3. If concerns: Raise them with your human partner before starting 4. 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:
1. **Execution mode affects architecture** - One-go vs batch determines review checkpoints, error recovery paths, and rollback points 2. **Implicit intent ≠ explicit choice** - "Don't wait" might mean "use one-go" OR "ask quickly and proceed" 3. **AskUserQuestion takes 3 seconds** - It's not an interruption, it's a confirmation 4. **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 2.5: Context Switching for Multi-Module Plans
**If plan has tasks with `target:` and `working_directory:` fields:**
1. **Track current module:**
current_module = None
current_directory = "."
2. **Before each task, check for context switch:**
IF task.target != current_module AND current_module != None:
# Prompt user for confirmation
AskUserQuestion:
question: "Switching to {task.target} module at {task.working_directory}. Continue?"
header: "Context"
options:
- label: "Continue"
description: "Switch to {task.target} and execute task"
- label: "Skip task"
description: "Skip this task and continue with next"
- label: "Stop"
description: "Stop execution for manual review"
IF answer == "Continue":
current_module = task.target
current_directory = task.working_directory
ELIF answer == "Skip":
Mark task as skipped → proceed to next
ELSE:
Stop execution → report progress3. **Load module-specific PROJECT_RULES.md:**
IF {task.working_directory}/PROJECT_RULES.md exists:
Instruct agent to read module-specific rules
Module rules override root rules4. **Pass working directory to agent:**
Task(
subagent_type=task.agent,
prompt="Working directory: {task.working_directory}
Before executing, cd to the working directory:
cd {task.working_directory}
If PROJECT_RULES.md exists in this directory, read and follow it.
{task.prompt}"
)**Optimization:** To minimize context switches, batch tasks by module when possible:
- Original: [backend, frontend, backend, frontend]
- Optimized: [backend, backend, frontend, frontend]
- **Only reorder if no dependencies between modules**
---
Step 3: Execute Batch
**Default: First 3 tasks**
**Agent Selection:** Backend Go → `ring:backend-engineer-golang` | Backend TS → `ring:backend-engineer-typescript` | Frontend → `ring:frontend-bff-engineer-typescript` | Infra → `ring:devops-engineer` | Testing → `ring:qa-analyst` | Reliability → `ring:sre`
For each task: Check context switch (Step 2.5) → Mark in_progress → Dispatch to agent with working_directory → Follow plan steps exactly → Run verifications → Mark completed
Step 4: Run Code Review
**After each batch, REQUIRED:** Use ring:requesting-code-review (all 7 reviewers in parallel)
**Handle by severity:**
- **Critical/High/Medium:** Fix immediately (no TODO) → re-run all 7 reviewers
Read more
name: ring:executing-plans description: | Controlled plan execution with human review checkpoints - loads plan, executes in batches, pauses for feedback. Supports one-go (autonomous) or batch modes. trigger: | - Have a plan file ready to execute - Want human review between task batches - Need structured checkpoints during implementation 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 sequence: after: [ring:writing-plans, ring:pre-dev-task-breakdown] related: 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
1. Read plan file 2. Review critically - identify any questions or concerns about the plan 3. If concerns: Raise them with your human partner before starting 4. 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:
1. **Execution mode affects architecture** - One-go vs batch determines review checkpoints, error recovery paths, and rollback points 2. **Implicit intent ≠ explicit choice** - "Don't wait" might mean "use one-go" OR "ask quickly and proceed" 3. **AskUserQuestion takes 3 seconds** - It's not an interruption, it's a confirmation 4. **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 2.5: Context Switching for Multi-Module Plans
**If plan has tasks with `target:` and `working_directory:` fields:**
1. **Track current module:**
current_module = None current_directory = "."
2. **Before each task, check for context switch:**
IF task.target != current_module AND current_module != None:
# Prompt user for confirmation
AskUserQuestion:
question: "Switching to {task.target} module at {task.working_directory}. Continue?"
header: "Context"
options:
- label: "Continue"
description: "Switch to {task.target} and execute task"
- label: "Skip task"
description: "Skip this task and continue with next"
- label: "Stop"
description: "Stop execution for manual review"
IF answer == "Continue":
current_module = task.target
current_directory = task.working_directory
ELIF answer == "Skip":
Mark task as skipped → proceed to next
ELSE:
Stop execution → report progress3. **Load module-specific PROJECT_RULES.md:**
IF {task.working_directory}/PROJECT_RULES.md exists:
Instruct agent to read module-specific rules
Module rules override root rules4. **Pass working directory to agent:**
Task(
subagent_type=task.agent,
prompt="Working directory: {task.working_directory}
Before executing, cd to the working directory:
cd {task.working_directory}
If PROJECT_RULES.md exists in this directory, read and follow it.
{task.prompt}"
)**Optimization:** To minimize context switches, batch tasks by module when possible:
- Original: [backend, frontend, backend, frontend]
- Optimized: [backend, backend, frontend, frontend]
- **Only reorder if no dependencies between modules**
---
Step 3: Execute Batch
**Default: First 3 tasks**
**Agent Selection:** Backend Go → `ring:backend-engineer-golang` | Backend TS → `ring:backend-engineer-typescript` | Frontend → `ring:frontend-bff-engineer-typescript` | Infra → `ring:devops-engineer` | Testing → `ring:qa-analyst` | Reliability → `ring:sre`
For each task: Check context switch (Step 2.5) → Mark in_progress → Dispatch to agent with working_directory → Follow plan steps exactly → Run verifications → Mark completed
Step 4: Run Code Review
**After each batch, REQUIRED:** Use ring:requesting-code-review (all 7 reviewers in parallel)
**Handle by severity:**
- **Critical/High/Medium:** Fix immediately (no TODO) → re-run all 7 reviewers
Proven engineering practices, enforced through skills. Ring is a comprehensive skills library and workflow system for AI agents that transforms how AI assistants approach software development.
Repo: LerianStudio/ring
Other skills on ring.
- /analyzing-options
Analyzing different approaches for a task or problem with structured comparisons, effort estimates, and recommendations. Use when facing strategic decisions, architecture choices, or multiple viable approaches. Skip when there's an obvious single approach or the decision is
Open skill - /auditing-production-readiness
Auditing a service's production readiness against Ring engineering standards across base dimensions plus a conditional multi-tenant dimension, then emitting a scored report and an HTML dashboard. Use before production deploy, periodic review, onboarding, or a major release. Skip
Open skill - /cleaning-comments
Cleaning redundant and obvious comments following clean code principles while preserving meaningful documentation. Supports git scope filtering (staged, unstaged, branch, commit-range). Use when code has excessive comments, during code review, or post-refactor cleanup. Skip when
Open skill - /committing-changes
Commit changes with scope allowlist enforcement, atomic grouping, GPG-signed conventional commits, and trailer management. Detects the repo's PR-validation scope policy before proposing any message. Use when the user asks to commit or has changes ready to record. Skip when the
Open skill - /creating-handoffs
Creating a handoff document that captures session state (completed work, decisions, open items, next steps) and delivering it via Plan Mode so the user gets the native 'clear context and continue implementing' resume option. Use when ending a session, when context grows large,
Open skill - /creating-worktrees
Creating an isolated git worktree for parallel branch work: selects the directory by priority order, verifies/adds .gitignore safety, auto-installs the detected toolchain's dependencies, runs a baseline test, and reports readiness. Use before a feature that needs isolation from
Open skill

