executing-plans
/executing-plans
Execute a written implementation plan task by task, reviewing it critically first, following each step exactly, running every verification, and stopping to ask rather than guessing when blocked. Use when you have a plan document (such as one from the writing-plans skill) and need to implement it in this session.
- Author
- khaledsaeed18 ↗
- Repository
- dotclaude ↗
- Licence
- MIT
- Last repository change
- 25.10.2026
Assessment and security
- Files in this package
- 1
- Scripts
- 0
- HTML comments
- 0
- URLs in SKILL.md
- 1
No signals detected. Repository changed on 25.10.2026, without references to retired models or APIs.
MIT, open: use and modify while retaining author attribution.
What it does and when to use it
Execute a written implementation plan task by task, reviewing it critically first, following each step exactly, running every verification, and stopping to ask rather than guessing when blocked. Use when you have a plan document (such as one from the writing-plans skill) and need to implement it in this session.
Original author description
Execute a written implementation plan task by task, reviewing it critically first, following each step exactly, running every verification, and stopping to ask rather than guessing when blocked. Use when you have a plan document (such as one from the writing-plans skill) and need to implement it in this session.
How it works
- Step 1: Load and review the plan critically
- Step 2: Execute task by task
- Step 3: Stop and ask when blocked
- Step 4: Finish the work
- Keep in mind
- Attribution
SKILL.md preview
--- name: executing-plans description: Execute a written implementation plan task by task, reviewing it critically first, following each step exactly, running every verification, and stopping to ask rather than guessing when blocked. Use when you have a plan document (such as one from the writing-plans skill) and need to implement it in this session. --- Take a finished implementation plan and turn it into working code, one task at a time, without drifting from what the plan says. The plan has already done the thinking and the decomposition; your job is faithful execution plus the judgement to stop when something is genuinely wrong. ## Step 1: Load and review the plan critically Read the whole plan before doing anything. Don't take it on faith, look for gaps, contradictions, steps that can't work, or instructions you don't actually understand. If you have real concerns, raise them with the user before you start, not halfway through. If it's sound, create a task list from it and begin. If the work isn't already isolated and the plan calls for it, set up an isolated workspace first with the `git-worktrees` skill. Never start implementing on `main` or `master` without the user's explicit consent. ## Step 2: Execute task by task For each task, in order: - Mark it in progress. - Follow each step exactly as written: the steps are deliberately bite-sized, so do them as given rather than collapsing or reordering them. - Run every verification the plan specifies. Don't skip a test or a build because the code "looks right." - Mark it complete only once its verifications actually pass. Don't bundle in changes the plan didn't ask for. If you spot something worth doing that's outside the plan, note it and raise it; don't silently fold it into a task. ## Step 3: Stop and ask when blocked Stop immediately (don't guess or work around it) when: - You hit a blocker: a missing dependency, a test that won't pass, an unclear instruction. - The plan has a gap that prevents you from starting or continuing a task. - A verification keeps failing and you don't understand why. - The approach itself looks wrong once you're in the code. Ask for clarification rather than improvising. If the user updates the plan in response, return to Step 1 and re-review the changed parts before continuing. ## Step 4: Finish the work Once every task is done and its verifications pass, don't just stop, wrap up the branch deliberately using the `finish-branch` skill, which verifies the full test suite and walks through how to integrate the work (merge, PR, keep, or discard). ## Keep in mind - Review the plan critically before trusting it; follow it exactly once you do. - Never skip a verification step. - When the plan references another skill, use it. - Stop when blocked instead of guessing. - Don't claim a task is done off a code change alone: the `verify-completion` skill is the standard here: run the check, read the output, then claim the result. ## Attribution Adapted from the `executing-plans` entry of [superpowers](https://github.com/obra/superpowers) by Jesse Vincent (MIT). The structure and the core rules are theirs; the wording, the examples, and the integration with this registry's other items are this repository's.
Versions
| Repository | Score | Licence |
|---|---|---|
| This page · khaledsaeed18/dotclaude | 100 | MIT |
| nikospavlopoulos/devops-mutant-powers | 100 | MIT |
| arklab/ark.tools | 100 | MIT |
| arklab/ark.tools | 100 | MIT |
| ongtungduong/legion | 100 | MIT |
| osmontero/opencode-skills | 100 | MIT |
| GanyuanRan/Aegis | 100 | MIT |
| seaworld008/commonly-used-high-value-skills | 100 | MIT |
| FrancoStino/opencode-skills-collection | 100 | MIT |
Identical content appears in 1 other GitHub folders. We show one copy with the highest score.
Database snapshot: 13.11.2026 · package version d0101f08a4c3 (SHA-256 digest of the entire package)
Downloads in the last 30 days: 0 · ranking
Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.
Similar skills
- 90sr-executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints - 90executing
Runs a written plan task by task with checks and a final review. Use when a plan exists and the user says go, implement it, execute the plan, or build the planned feature. Not for writing plans, single edits or reviews. - 90evanflow-executing-plans
Execute a written implementation plan task-by-task with inline verification. Stop and ask on blockers. No forced sub-skill chains. Use when a plan exists and you're ready to implement. - 100execute
Execute an approved implementation plan from .ai/plans/ task by task, running each task's verification and committing per task via the check-and-commit gate. Use when asked to "execute the plan", "implement the plan", or after /plan approval. Do not use without an approved plan… - 100reviewing-plans
Use when reviewing an implementation plan critically before executing it, especially when the user has not read the plan and needs a surface of inconsistencies, rule violations, documentation drift, and questionable scope or guardrail claims. Triggers between writing-plans and… - 100implement
Use when executing an implementation plan under docs/plans/ (for example one written by start-ticket), or when asked to implement the next planned task or the whole plan ("auto").