The prompt library

Your very first message on any new project. Ten minutes here saves hours of credits, because most wasted credits build the wrong thing convincingly.

Before you write any code, help me write a specification.

I want to build: [two or three sentences]
The person using it is: [who, specifically]
The one thing it must do well: [the single core job]
Success looks like: [one checkable outcome — e.g. "a stranger signs up and completes X without help"]

Interview me first. Ask up to eight questions, one at a time, covering:
- The data I am storing and where it comes from
- Who can see and change each piece of data
- What happens when things go wrong: bad input, no network, duplicate submissions
- What is explicitly OUT of scope for version one

Then write a spec.md, one page maximum:
1. The problem, in plain language
2. User stories with acceptance criteria I could verify by clicking
3. The data model — every table, every field, its type, who owns each row
4. Permissions: who can read and write what
5. Out of scope for v1

If I am vague, push back and make me choose. Do not write application code until I approve the spec. After approval, treat it as the contract — if a later request contradicts it, say so before building.

Save the result as AGENTS.md in your project root. Every serious agent — Claude Code, Cursor, Codex, Copilot, Devin — reads it automatically at the start of a session.

Create an AGENTS.md file in the project root with these rules, then follow it for the rest of this project:

## Stack
[framework, database, auth, host — fill in]

## Rules
- Prefer the simplest solution that works. Ask before adding any dependency.
- Never invent an API, package, or config option. If you are not certain it exists, say so.
- Every new database table gets row-level security enabled and an owner-scoped policy in the same change that creates it. Never USING (true).
- Secrets live in environment variables, server-side only. Never in code that reaches the browser, never in git.
- Small changes, one feature per session. Never rewrite or delete a file wholesale without listing it first and asking.
- Run the existing tests before declaring anything done. If nothing tests what you changed, say so.
- After every change, tell me exactly what to click or run to verify it worked.

## When you get stuck
Stop after two failed attempts at the same fix. Explain what you tried, what you observed, and your best theory. Do not try a third time without new information.

Keep this file under a page. When a rule stops being true, delete it.

When the thing you want is too big to build in one go — which is most things worth building.

Here is what I eventually want to build:

[paste your spec or description]

Break it into a sequence of versions where each one is independently useful — something I could put in front of a real person and learn from, not a technical milestone.

Output a table: version | one-sentence outcome | what a user can now do that they could not before | the riskiest assumption it tests | rough number of build sessions.

Order by risk: the version that tests the scariest assumption comes first, even if it is not the easiest to build. For each version, name the one signal that would prove it worked.

Then tell me which single version to build this week, what to deliberately leave rough, and — honestly — which parts of my idea should probably never be built at all.