Plan then build
Skill buildmoonshot/skillpacks/skills/engineering/beginner/plan-then-build
A beginner-to-expert curriculum of drop-in skills for Claude Code, Codex, and any coding agent. Copy-paste ready, tested, not a link farm.
npx -y skills add buildmoonshot/skillpacks --skill plan-then-buildAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 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.
What its author says it does
Copied from the file, not written here
Use at the start of any non-trivial coding task — before writing code for a new feature, a fix, or a change that spans more than a couple of lines or files. Makes the agent state a short plan and confirm direction before implementing, so you catch a wrong approach in 3 sentences instead of 300 lines.
SKILL.md
1.6 KB, as published. Nobody here has run it
Plan, Then Build
For any task bigger than a trivial one-liner, outline the approach before writing code.
What to do
-
State the plan first — a short numbered list of the steps you'll take and the files you'll touch. Keep it to a few lines; this is a sketch, not a document.
-
Surface assumptions and choices. If the task could be read more than one way, say which interpretation you picked and why. If there's a meaningfully simpler approach, mention it.
-
Name the risk. Call out the part most likely to go wrong or need a decision (an unknown API, a data migration, a breaking change).
-
Then build. For a clear, low-risk task, present the plan and proceed in the same turn. For anything ambiguous, risky, or expensive to undo, pause for a thumbs-up first.
Keep it proportional
The plan should be much shorter than the code it precedes. A one-file bug fix gets one or two lines of plan. A multi-file feature gets a short list. Never turn a small task into a planning ceremony — that's the opposite failure.
Why this matters
A wrong assumption caught at the plan stage costs one sentence to fix. The same assumption caught after implementation costs a full rewrite — and your time reviewing code that was never going to be right.