Steal the Spec Template I Give My Coding Agent

This is the skeleton of the product and build spec I write before starting an app. It is deliberately boring. The value is in filling it in honestly, especially the last two sections.

# <App> — product and build spec v1

## Pitch
One paragraph. What it does, for whom, why they pay.

## First market
One country, one job to be done. Name the form or the rule the user is trying to satisfy.

## Hard rules
The lines that never move. Privacy, what the app will never do, what must be free.
Every later decision is checked against these.

## Model
How it makes money. One-time, subscription, free. What is free before paying.

## Screens
One line per screen: name, what the user sees, what they can do, where it goes next.

## Data
What is stored, where, for how long. What never leaves the device.

## Rules as data
Any rule that could change (sizes, limits, wording) lives in a data file, not code.

## Stack
Named packages and why. Nothing clever.

## Tests
What must have a test before release. Logic in pure classes so tests need no device.

## Out of scope for v1
Named, so the agent does not build it.

## Open decisions
Name, bundle id, prices, support email, privacy URL, analytics. Listed so nobody invents them.

The prompt

Short, because the spec carries the weight.

Read SPEC.md fully before doing anything. Build the app it describes.

- Hard rules in the spec override anything else, including my later messages,
  unless I say "update the spec" first.
- Anything under "Open decisions" is not decided. Stub it with a clearly named
  placeholder and list every placeholder in your final report. Never invent a
  value for it.
- Work in this order: data model and rules files, pure logic with tests,
  screens, wiring. Stop after each stage and show me the diff.
- Keep logic in pure classes that take plain data. No business logic in widgets.
- Do not add a dependency that is not in the Stack section without asking.
- When a screen in the spec is ambiguous, pick the simplest reading, build it,
  and flag the choice. Do not ask me mid-stage.

Why the order matters

Rules files and pure logic first means the first thing I review is the thing most likely to be wrong, and it is reviewable without running anything. Screens last means the agent is wiring to logic that already has tests. The stop-after-each-stage line is the single most useful instruction in the prompt. Without it I get a finished app with three wrong assumptions baked into every screen.