---
name: build
description: Use when you're about to actually build something with an AI — an app, a feature, a tool, an automation — and you want it to end up working, not spiral into a mess. Especially when you're handing the build to an AI agent (Claude Code, Cursor, Cowork): when past builds went off the rails, when the AI over-built or quietly broke things, when it said "done" but it wasn't, or when you just don't know how to keep a build on track. The execution partner to the `prd` skill — `prd` writes the brief, this ships it.
---

# Build — Ship It Without It Spiralling

## Overview

A skill for one job: **take a clear idea and build it with an AI so it actually ends up working** — slow at the start, fast after, never a runaway. This is the discipline that separates "I built a real thing" from "the AI and I made a mess and I don't know what's broken."

**The core move:** *plan → small slice → verify it works → next slice.* Never build the whole thing in one giant leap and hope. Build the smallest piece that works, **see it work with your own eyes**, then add the next.

**Core principle:** *"The AI said it's done" is not done. Done is when you've seen it work.* The single most expensive habit in AI building is trusting a confident "all set!" without checking. A builder is confident in its own output by construction — so it can't be the only thing that verifies it.

**Announce at start:** "I'm going to build this in slices — plan first, smallest working piece next, and I'll verify each piece actually works before moving on. Slower at the start, but it won't spiral."

## When to use

- You have an idea or a `prd` and you're about to build it (especially handing it to an AI agent).
- Past builds went sideways — the AI over-built, broke working things, or "finished" something that didn't work.
- You're non-technical and want a way to *keep the AI on track* without reading the code.
- Anything where "it has to actually work at the end" matters.

## When to skip

- You haven't decided *what* to build yet — write the brief first (`prd`), or pressure-test the idea (`red-team`).
- A throwaway experiment where breaking things is the point — just play.

## The method

Go slow at the start so you can go fast later. The order is the discipline.

### 1. Start from a brief, not a vibe
Build from a clear spec — ideally a `prd`. "Vibe coding" (just describing it as you go) is where scope drift and the-wrong-thing come from. If you don't have a brief, write a quick one first: what it does, what "done" looks like, and what it must **not** do.

### 2. Plan before building — and review the plan yourself
Have the AI **propose its plan/approach before it writes anything** (in Claude Code, that's plan mode). Then *you* read the plan — not the code, the plan, in plain English. This is where you catch over-engineering, the wrong approach, or scope creep **before** it becomes code that's expensive to unpick. If the plan's wrong, fix the plan; don't let it start.

### 3. Slice it small — smallest valuable piece first
Don't build the whole thing in one pass. Pick the **smallest slice that does something real** and build only that. Then the next. (Practical reason: AI agents get worse the more you ask of them at once — they drift past a couple hundred instructions. Human reason: one working slice teaches you more than ten planned ones, and you always have something that works.)

### 4. Build one slice — then VERIFY it actually works
After each slice, **see it work yourself** — run it, click it, look at the output. Don't accept "done" on trust. Ask: *does it do the thing the brief said, including when I give it something weird (empty, wrong, too big)?* If you can't tell whether it works, that's a gap — make the AI show you. **The maker can't be the only checker.**

**How to verify when you can't read the code** — this is the whole game for a non-technical builder, so don't skip it:
- **Make it prove it, not claim it.** "Show me it working on this exact input", then look at the real output, not the reassurance around it.
- **Test with something you already know the answer to.** You don't need to read code to check that the right number, the right file, or the right screen came out.
- **Poke the edges on purpose.** "Now show me what happens when it's empty, when it's wrong, when it's huge." Happy-path-only is not verified.
- **Get a second pair of eyes.** Open a fresh chat, or a second AI, and ask it to check the work. The builder is confident by construction, so it can't be the only judge.
- **Check against your "done".** You already wrote what done looks like, so confirm *that exact thing* happened, not something that merely looks finished.

### 5. Keep it on the rails — a rules file
Give the AI a short rules file it reads every time (in Claude Code that's `CLAUDE.md`; the open standard is `AGENTS.md`). It's the memory the AI doesn't have across sessions. Put in it: what to **always** do, what to **ask first** about, and what to **never** do (e.g. *"never delete working files", "ask before adding anything new", "don't change things I didn't ask you to change"*). This is your main defence against scope drift and "it helpfully rewrote half my app."

### 6. Save a known-good version before each change
Before each new slice, **checkpoint** the working version (commit it, or save a copy). Then if the next change breaks something, you can always get back to working. Building without a way back is how a good build becomes an unrecoverable one.

### 7. When something breaks, find the cause — don't pile on fixes
If a slice doesn't work, resist letting the AI throw fix after fix at it. Stop and find the **actual cause** first (what changed, what's the real error, reproduce it). Two moves that work even if you can't read code: ask the AI to *explain what it thinks broke and why, before it changes anything*, and go back to your last checkpoint and re-apply just the one change, so you can see exactly what introduced the break. Patching symptoms on a broken foundation buries the problem deeper.

## A tiny worked example

Slicing and verifying, in miniature. Goal: *a tool that emails me a summary of yesterday's sales every morning.*

- **Slice 1** — read yesterday's sales and show the total. *Verify:* I check the total against the spreadsheet myself. Right? Move on.
- **Slice 2** — turn it into a short written summary. *Verify:* I read it; it matches the numbers.
- **Slice 3** — email it to me automatically each morning. *Verify:* I wait one morning; the email arrives and it's correct.

Three small slices, each one *seen* working, beats one giant "it's all done" I can't actually check.

## The loop — iterate to a bar, per slice

The whole skill is a loop, run once per slice:

- **Per slice:** plan → build → **verify it works** → checkpoint → next slice.
- **The bar for "this slice is done":** you have *seen it do the thing* (not been told), including the obvious edge cases, and nothing that worked before is now broken.
- **The bar for "the build is done":** the brief's measurable "done" is met — you've watched it happen.
- **Stop** when the bar's met. Don't keep "improving" a working build the brief didn't ask for — that's how you re-break it. (If you're tempted, that's a *new* brief, decided deliberately.)

## Output shape

> 1. **The plan** — the slices, in order, smallest-valuable-first.
> 2. **The rails** — the few Always / Ask-first / Never rules for this build.
> 3. **Per slice, as you go:** what was built → *how you verified it works* → checkpoint.
> 4. **Done** — the brief's "done" met, demonstrated (not asserted).

## Honesty rules (non-negotiable)

- **"Done" means you've seen it work.** Never accept a build as finished on the AI's say-so. Run it. Look.
- **Plan before code.** If the AI starts building before you've reviewed the approach, stop it. The plan is the cheap place to be wrong.
- **Small slices beat big bangs.** A working small thing is worth more than an impressive broken big thing.
- **Always have a way back.** Checkpoint working versions. A build with no undo is one bad change from gone.
- **Find the cause before the fix.** Stacking fixes on an unknown cause makes it worse, not better.

## Common mistakes / red flags — STOP

- **Vibe-building the whole thing at once.** One giant prompt, one giant result, no idea what works. Slice it.
- **Trusting "done".** Accepting "I've finished!" without running it. Verify, every time.
- **Skipping the plan review.** Letting it code immediately → over-engineering and wrong-approach slip in. Read the plan first.
- **No rules file.** No Always/Ask/Never → the AI drifts, over-builds, and changes things you didn't ask about. Add the rails.
- **No checkpoints.** Building with no save-points → one bad slice and you can't get back to working. Save known-good versions.
- **Fix-stacking.** Throwing patch after patch at a break instead of finding the cause. Stop and diagnose.

## Related skills

- `prd` — writes the brief this skill builds from (do `prd` first).
- `red-team` — pressure-test the idea *before* you commit to building it.
- `the-loop` — refine a single piece of output to a quality bar (zoom-in companion to this build-level loop).