# Prompt pack: plan a feature before coding (spec → tasks → acceptance tests)

Use these three prompts in order, in the same chat or agent session. Review the output of each one before you send the next.
Ask the agent not to write code until prompt 3 is done and you have approved the plan.

---

## Prompt 1: Write the spec (no code)

I want to add a feature to this project. Do not write or change any code yet.
First, read the parts of the codebase this feature will touch, then write a short spec.

Feature idea: [DESCRIBE THE FEATURE IN 2–5 SENTENCES, IN YOUR OWN WORDS]
Who it is for and why: [USER AND THE PROBLEM IT SOLVES]
Constraints: [e.g. "no new dependencies", "must work on mobile", "keep the free tier limits", "ship in one day"]

Write the spec with these sections:
1. Goal — one sentence.
2. User stories — 2 to 5, in the form "As a [user], I want [action], so that [benefit]".
3. Scope — what is in, and what is explicitly out (non-goals).
4. User flow — numbered steps of what the user sees and does, including empty, loading and error states.
5. Data — new or changed data (fields, types, where it is stored), and any migration needed.
6. Affected code — the files, modules or routes you expect to change, based on what you read. Mark anything you are unsure about.
7. Risks and open questions — edge cases, security or privacy concerns, performance, and the questions I need to answer.

Keep it under one page. Ask me the open questions at the end and wait for my answers.

---

## Prompt 2: Break it into tasks

Thanks. Here are my answers to the open questions: [YOUR ANSWERS]
Update the spec with these answers, then break the work into small tasks. Still no code.

Rules for the task list:
- Each task should be small enough to finish and review in one sitting, and leave the app in a working state.
- Order the tasks so the riskiest or most uncertain part comes first.
- For each task, give: a short title, the files it touches, what "done" means, and how to verify it (a command, a test, or a manual check).
- Mark tasks that need a decision from me, a new dependency, a schema change or a secret/API key.
- Put anything nice-to-have in a separate "Later" list instead of the main plan.

---

## Prompt 3: Write acceptance tests first

Now write acceptance criteria and tests for this feature before implementing it.

1. Write acceptance criteria in Given / When / Then form, covering the main flow, the empty state, at least two error cases and at least one edge case.
2. Turn the criteria into automated tests using the test setup this project already has ([TEST FRAMEWORK, e.g. Vitest, Jest, pytest, Playwright]). If there is no test setup, propose the smallest one and wait for my approval before adding it.
3. Run the new tests and show me that they fail for the right reason (the feature does not exist yet), not because of a typo or a broken setup.
4. List any criteria that are hard to automate, and describe how I should check them by hand.

When I approve the tests, implement the tasks one at a time, in order. After each task: run the tests, show me what changed, and wait for me to say "next".