| name | executing-plans |
| description | Execute implementation plans step-by-step with quality guardrails (ask when unclear, minimal-change bias, readability checklist, verification). Use when the user asks to execute or follow a plan, run tasks sequentially from a plan file (e.g., docs/plans/*.md), or continue plan steps. |
Executing Plans
Overview
Execute an existing plan task-by-task with strong clarity, minimal change, and verification. The plan is the source of truth; do not improvise or refactor beyond it without asking.
Quick Start
- Announce: "I'm using the executing-plans skill to run the plan."
- Locate plan: Use the provided file path or inline plan text; ask if missing.
- Confirm start: Ask which task to begin with if not explicit.
Execution Workflow
Pre-flight
- Read the target plan section.
- Identify any unclear items (missing files, ambiguous commands, unclear intent).
- Ask a single, precise question if anything is unclear. Do not guess.
Task Loop (for each Task N)
- Restate the step goal in plain language.
- Open/inspect only the files listed in the task.
- Follow the plan steps in order (test → run → implement → run → checklist).
- Do not commit. If the plan includes commit steps, skip them and note the skip.
- Use minimal changes to satisfy the step; avoid refactors unless explicitly required.
- If a new file or modification seems necessary but not listed, ask first.
Ambiguity Rule
- Ask whenever something is unclear, regardless of the step.
- Ask one question at a time with concrete options when possible.
Minimal-Change Bias
- Preserve existing style, structure, and formatting.
- Touch only the files listed in the task.
- Avoid reformatting or cleanup unless the plan says so.
Readability/Style Checklist (after each task or file edit)
- Naming: Clear, explicit names; no ambiguity.
- Structure: Minimal and localized; no unnecessary nesting or indirection.
- Readability: Intent is obvious to a new reader.
- Errors: Failure modes are explicit; no silent failure unless intended.
- Consistency: Matches existing patterns in the file.
- Docs/Comments: Add only if intent is not obvious from code.
If the checklist suggests changes beyond the plan, ask before doing them.
Verification and Failures
- Run the exact commands specified in the plan when possible.
- Do not claim completion without verification.
- If tests fail or behavior is unexpected, switch to the systematic-debugging skill (if available).
- If verification is blocked (permissions or environment), explain and ask for next steps.
Reporting and Progress
- After each task: summarize changes with file paths and tests run (plus results).
- Ask to proceed to the next task.