Executing plans
Skill KhaledSaeed18/dotclaude/skills/engineering/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.From its SKILL.md
npx -y skills add KhaledSaeed18/dotclaude --skill executing-plansAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.9 KB, 572 tokens by cl100k_base, as published. Nobody here has run it
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-completionskill is the standard here: run the check, read the output, then claim the result.
What ships with it: 1 file
939 B alongside SKILL.md
- registry.json939 B
Gives 0 of the 12 instructions most docs writing skills give in 572 tokens
Counted across 1,637 of the 3,044 authors here whose files we hold, read 2026-08-07
- Announce the skill at startin 54 of 1637, across 26 files
- Convert legacy doc files before editingin 45 of 1637, across 7 files
- Predict questions readers might askin 42 of 1637, across 4 files
- Generate clarifying questions for initial contextin 42 of 1637, across 3 files
- Create document scaffold with placeholder textin 42 of 1637, across 3 files
- Brainstorm content options for each sectionin 42 of 1637, across 3 files
- Test the document with a fresh context-less instancein 42 of 1637, across 3 files
- Include exact file paths in every taskin 42 of 1637, across 15 files
- Ask interview questions one at a timein 42 of 1637, across 27 files
- Apply surgical edits during refinementin 41 of 1637, across 2 files
- Offer structured workflow or freeformin 40 of 1637, across 1 file
- Ask for document meta-contextin 40 of 1637, across 2 files
Said here and by no other author read
- raise plan concerns before implementing
- create a task list from the plan
- execute tasks in order
- follow each step exactly as written
- run every verification the plan specifies
- mark tasks complete only when verifications pass
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.