ring%3aexecuting-plans（环%3a 执行计划）

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:

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 progress
3. 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 rules
4. 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 → 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 7 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

Blocker Criteria

STOP and report if:

Cannot Be Overridden

The following requirements CANNOT be waived:

• AskUserQuestion for execution mode is MANDATORY - user intent does NOT skip this step
• Code review after each batch is REQUIRED - all 7 reviewers in parallel
• Critical/High/Medium issues MUST be fixed immediately - TODO comments are FORBIDDEN for these severities
• Context switch confirmation is REQUIRED when switching between modules
• Full test suite MUST pass before completing development

Severity Calibration

Pressure Resistance

Anti-Rationalization Table