Founder pack
Claude Skill
Execution Plan Writer
Turns an approved spec into a sequenced, bite-sized execution plan — files, tasks, tests, commits — anyone could pick up and run.
What it does
Takes a spec or set of requirements and writes an implementation plan that assumes the builder has zero context for the codebase: which files each task touches, the order to do them in, how to test each step, and frequent commit checkpoints. Decomposes the work into small, independently-shippable tasks, and splits multi-subsystem specs into separate plans.
When to use
- ✓Handing a spec to an engineer or AI agent to build
- ✓A multi-step project that needs sequencing before anyone starts
- ✓You want a plan a stranger to the codebase could execute correctly
When not to use
- ✗You're still deciding WHAT to build — pin the spec down first
- ✗A single-step change that doesn't need a plan
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/execution-plan-writer.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: execution-plan-writer
description: Use when you have an approved spec for a multi-step task and need an implementation plan before touching code. Triggers on "write a plan", "implementation plan", "break this into tasks", "execution plan", "how do we build this".
---
# Execution Plan Writer
Write the plan as if the person executing it is a skilled engineer who knows almost nothing about this codebase or problem domain — and has questionable taste. Document everything: which files to touch per task, how to test, what to check, when to commit.
## Scope check first
If the spec spans multiple independent subsystems, split it into one plan per subsystem. Each plan should produce working, testable software on its own. A single mega-plan across unrelated subsystems is a sign the spec wasn't decomposed.
## Map the files before writing tasks
Before listing tasks, lay out which files get created or modified and what each is responsible for. This is where decomposition gets locked in:
- One clear responsibility per file; files that change together live together
- Prefer smaller, focused files over large ones doing too much
- In an existing codebase, follow the established patterns — don't unilaterally restructure
## Bite-sized tasks
Each step is one action (a couple of minutes), in this rhythm:
- Write the failing test
- Run it, confirm it fails for the right reason
- Implement the minimal code to pass
- Run the tests, confirm green
- Commit
Frequent commits. DRY. YAGNI. Test-first where it fits.
## Plan header
Every plan opens with: a one-sentence **Goal**, 2-3 sentences on **Architecture/approach**, and the **Tech stack**. Then the tasks as a checklist so progress is trackable.
## Anti-patterns
- Tasks the size of "build the backend" instead of single actions
- Assuming the builder knows the codebase's conventions — spell them out
- No testing step between implement and commit
- One sprawling plan across unrelated subsystems
- Skipping the file map and letting structure emerge by accident
Example prompts
Once installed, try these prompts in Claude:
- Turn this approved spec into a step-by-step implementation plan — files to touch, tests, and commit points.
- Break this multi-subsystem spec into separate execution plans, one per subsystem.