run-plan
Run Plan
Loads a written plan document, reviews it critically, then executes tasks in dependency order using a worker-validator loop.
Core Principle
Do not follow plans blindly. If the plan has issues, flag them before executing. But if the plan is clear, execute it faithfully.
Hard Gates
- Read and review the plan first. Always review the entire plan before executing.
- Follow steps exactly. Do not skip or alter steps in the plan arbitrarily.
- Never skip verification. Test runs, expected output checks, and other verifications stated in the plan must be performed.
- Parallelizable tasks must always run in parallel. Tasks with no dependencies and no shared file modifications must be dispatched concurrently. Sequential grouping is prohibited.
- Worker and Validator must be separate subagents. The main agent must NOT perform worker or validator roles inline. Each must be dispatched as an independent subagent via the Agent tool.
- Validator must not receive worker output. The validator subagent receives only the plan's task goal and acceptance criteria. It must never receive the worker's diff, logs, or implementation details. The validator judges by reading the code and running tests independently.
- Stop when blocked. Do not guess. Ask the user.
When To Use
More from tmdgusya/engineering-discipline
clarification
Use when a user's request is vague, ambiguous, or underspecified. Launches an iterative Q&A loop to resolve ambiguity while a subagent explores the codebase in parallel. Outputs a clear, well-scoped context brief so the user can plan sharply. Triggers on "I want to...", "I need...", "let's build...", "can you help me...", "we should...", or any request where the full scope isn't immediately clear.
36rob-pike
Rob Pike's 5 Rules of Programming — a decision framework that prevents premature optimization and enforces measurement-driven development. Use when the user says "optimize", "slow", "performance", "bottleneck", "speed up", "make faster", "too slow", or any request to improve code speed/efficiency. Also use when you notice yourself about to suggest a performance optimization without measurement data. This is a thinking discipline, not a tooling workflow.
35systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior. Enforces a strict reproduce-first, root-cause-first, failing-test-first debugging workflow before fixing.
33plan-crafting
Use when a task's scope is clear and multi-step implementation is needed, before touching code. Triggered after clarification is complete, or when the user explicitly requests plan creation with a clear prompt.
32long-run
Orchestrates multi-day execution of complex tasks through milestones. Each milestone goes through plan-crafting, run-plan (worker-validator), and review-work phases with checkpoint/recovery. Triggers when the user says "long run", "start long run", "execute milestones", or "run all milestones".
30simplify
Review changed code for reuse opportunities, quality issues, and inefficiencies using three parallel review agents, then fix any issues found. Triggers when the user says "simplify", "clean up the code", "review the changes", or after run-plan execution when code quality verification is needed.
30