Initial commit
This commit is contained in:
Zhongwei Li
206
skills/executing-plans/SKILL.md
Normal file
206
skills/executing-plans/SKILL.md
Normal file
@@ -0,0 +1,206 @@
|
||||
---
|
||||
name: 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 subagent-driven-development
|
||||
- No plan exists → use writing-plans first
|
||||
- Plan needs revision → use brainstorming first
|
||||
|
||||
sequence:
|
||||
after: [writing-plans, pre-dev-task-breakdown]
|
||||
|
||||
related:
|
||||
similar: [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 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.**
|
||||
|
||||
Use `AskUserQuestion` to determine execution mode:
|
||||
|
||||
```
|
||||
AskUserQuestion(
|
||||
questions: [{
|
||||
header: "Mode",
|
||||
question: "How would you like to execute this plan?",
|
||||
options: [
|
||||
{ label: "One-go (autonomous)", description: "Execute all batches automatically with code review between each, no human review until completion" },
|
||||
{ label: "Batch (with review)", description: "Execute in batches, pause for human review after each batch's code review" }
|
||||
],
|
||||
multiSelect: false
|
||||
}]
|
||||
)
|
||||
```
|
||||
|
||||
**Based on response:**
|
||||
- **One-go** → Execute all batches continuously (Steps 3-4 loop until done, skip Step 5)
|
||||
- **Batch** → Execute one batch, report, wait for feedback (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 3: Execute Batch
|
||||
**Default: First 3 tasks**
|
||||
|
||||
**Agent Selection:** For each task, dispatch to the appropriate specialized agent based on task type:
|
||||
|
||||
| Task Type | Preferred Agent | Fallback |
|
||||
|-----------|-----------------|----------|
|
||||
| Backend (Go) | `ring-dev-team:backend-engineer-golang` | `general-purpose` |
|
||||
| Backend (Python) | `ring-dev-team:backend-engineer-python` | `general-purpose` |
|
||||
| Backend (TypeScript) | `ring-dev-team:backend-engineer-typescript` | `general-purpose` |
|
||||
| Backend (other) | `ring-dev-team:backend-engineer` | `general-purpose` |
|
||||
| Frontend (TypeScript/React) | `ring-dev-team:frontend-engineer-typescript` | `general-purpose` |
|
||||
| Frontend (other) | `ring-dev-team:frontend-engineer` | `general-purpose` |
|
||||
| Infrastructure | `ring-dev-team:devops-engineer` | `general-purpose` |
|
||||
| Testing | `ring-dev-team:qa-analyst` | `general-purpose` |
|
||||
| Reliability | `ring-dev-team:sre` | `general-purpose` |
|
||||
|
||||
**Note:** If plan specifies a recommended agent in its header, use that. If `ring-dev-team` plugin is unavailable, fall back to `general-purpose`.
|
||||
|
||||
For each task:
|
||||
1. Mark as in_progress
|
||||
2. Dispatch to appropriate specialized agent (or fallback)
|
||||
3. Agent follows each step exactly (plan has bite-sized steps)
|
||||
4. Run verifications as specified
|
||||
5. Mark as completed
|
||||
|
||||
### Step 4: Run Code Review
|
||||
**After each batch execution, REQUIRED:**
|
||||
|
||||
1. **Dispatch all 3 reviewers in parallel:**
|
||||
- REQUIRED SUB-SKILL: Use ring-default:requesting-code-review
|
||||
- All reviewers run simultaneously (not sequentially)
|
||||
- Wait for all to complete
|
||||
|
||||
2. **Handle findings by severity:**
|
||||
|
||||
**Critical/High/Medium Issues:**
|
||||
- Fix immediately (do NOT add TODO comments)
|
||||
- Re-run all 3 reviewers in parallel after fixes
|
||||
- Repeat until no Critical/High/Medium issues remain
|
||||
|
||||
**Low Issues:**
|
||||
- Add `TODO(review):` comments in code
|
||||
- Format: `TODO(review): [Issue description] (reported by [reviewer] on [date], severity: Low)`
|
||||
- Track tech debt at code location for visibility
|
||||
|
||||
**Cosmetic/Nitpick Issues:**
|
||||
- Add `FIXME(nitpick):` comments in code
|
||||
- Format: `FIXME(nitpick): [Issue description] (reported by [reviewer] on [date], severity: Cosmetic)`
|
||||
- Low-priority improvements tracked inline
|
||||
|
||||
3. **Only proceed when:**
|
||||
- Zero Critical/High/Medium issues remain
|
||||
- All Low/Cosmetic issues have TODO/FIXME comments
|
||||
|
||||
### Step 5: Report and Continue
|
||||
|
||||
**Behavior depends on execution mode chosen in Step 2:**
|
||||
|
||||
**One-go mode:**
|
||||
- Log batch completion internally
|
||||
- Immediately proceed to next batch (Step 3)
|
||||
- Continue until all tasks complete
|
||||
- Only report to human at final completion
|
||||
|
||||
**Batch mode:**
|
||||
- Show what was implemented
|
||||
- Show verification output
|
||||
- Show code review results (severity breakdown)
|
||||
- Say: "Ready for feedback."
|
||||
- Wait for human response
|
||||
- Apply changes if requested
|
||||
- Then proceed to next batch (Step 3)
|
||||
|
||||
### Step 6: Complete Development
|
||||
|
||||
After all tasks complete and verified:
|
||||
- Announce: "I'm using the finishing-a-development-branch skill to complete this work."
|
||||
- **REQUIRED SUB-SKILL:** Use ring-default:finishing-a-development-branch
|
||||
- Follow that skill to verify tests, present options, execute choice
|
||||
|
||||
## When to Stop and Ask for Help
|
||||
|
||||
**STOP executing immediately when:**
|
||||
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
|
||||
- Plan has critical gaps preventing starting
|
||||
- You don't understand an instruction
|
||||
- Verification fails repeatedly
|
||||
|
||||
**Ask for clarification rather than guessing.**
|
||||
|
||||
## When to Revisit Earlier Steps
|
||||
|
||||
**Return to Review (Step 1) when:**
|
||||
- Partner updates the plan based on your feedback
|
||||
- Fundamental approach needs rethinking
|
||||
|
||||
**Don't force through blockers** - stop and ask.
|
||||
|
||||
## Remember
|
||||
- Review plan critically first
|
||||
- **MANDATORY: Use `AskUserQuestion` for execution mode** - NO exceptions, even if user says "don't ask"
|
||||
- **Use specialized agents:** Prefer `ring-dev-team:*` agents over `general-purpose` when available
|
||||
- Follow plan steps exactly
|
||||
- Don't skip verifications
|
||||
- Run code review after each batch (all 3 reviewers in parallel)
|
||||
- Fix Critical/High/Medium immediately - no TODO comments for these
|
||||
- Only Low issues get TODO comments, Cosmetic get FIXME
|
||||
- Reference skills when plan says to
|
||||
- **One-go mode:** Continue autonomously until completion
|
||||
- **Batch mode:** Report and wait for feedback between batches
|
||||
- Stop when blocked, don't guess
|
||||
- **If rationalizing why to skip AskUserQuestion → You're wrong → Ask anyway**
|
||||
Reference in New Issue
Block a user