Skip to content
Back to skills

Plan Then Build

ASecurity

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.

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added September 7, 2026
ai-agentsgoapi

Works with

  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 7, 2026

npx -y skills add buildmoonshot/skillpacks --skill plan-then-build --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Plan Then Build?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Plan Then Build
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/buildmoonshot-plan-then-build/badge)](https://www.skillsdirectory.com/skills/buildmoonshot-plan-then-build)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: plan-then-build
description: 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.
---

# Plan, Then Build

For any task bigger than a trivial one-liner, **outline the approach before writing code.**

## What to do

1. **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.

2. **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.

3. **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).

4. **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.

Files in this skill

  • README.md1.5 KB
  • SKILL.md1.6 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…