# spec first

Second blocking step: a short written spec before any work — goal, scope, assumptions, approach, and what done means.

## What it is
Before code, a short spec: the real goal in one line, what's in and out of scope, the assumptions I'm making, the approach, and the acceptance criteria. Terse prompts under-specify intent; the spec forces the real outcome to be named before anything gets built.

## Why
My prompts are often terse — “fix”, “move it”, “make it work.” A spec forces the real goal, scope, and definition of done into writing before any code exists, so the agent builds the right thing once instead of guessing and reworking.

## How Andrew uses it
Every task gets one, scaled to size — a one-line fix gets a two-line spec, a feature gets a full one. The acceptance criteria pair with the verification plan: the spec defines done, the verification proves it. When intent is genuinely vague, the spec surfaces the one clarifying question worth asking instead of guessing.

## How to get it
The whole method is downloadable and adaptable — `method/steps/spec-first.md` inside the zip. The template is five headings; the discipline is writing it before the first edit, every time.

_Distilled from: ~/.claude/CLAUDE.md § Always write a spec first_
