New Feature

---
name: new-feature
description: The intake for any feature a user would notice - grill the founder, write the spec and requirement rows, pass the readiness gate, then route design, build, QA and reviews. Use whenever the founder asks for something new.
---

# New feature

## 1. Open the work folder

Reserve the next requirement id for the feature's area (`skills/requirement-first/`) and create
`docs/work/<ID>-<slug>/status.md` with the track, the date and "intake".

## 2. Grill

Run `skills/grilling/` on the feature. The tree always includes these branches; skip one only
by saying why it does not apply:

- **Who and why:** which user, what they are trying to do, what they do today without it, how
  we will know it worked (a number and a date).
- **Scope:** the smallest version worth shipping, what is explicitly out, what can wait.
- **Behaviour:** the main flow, every error, empty and edge state, what happens to existing
  users and existing data.
- **Data:** what is stored, for how long, who can see it, how it is deleted. Personal data,
  payments, children, health or AI output each pull in `legal` and `security`.
- **Regions:** does it change anything under the packs in `docs/legal/regions/`?
- **Cost:** new services, their price at 10 times today's usage.
- **Done:** what `qa` will check, row by row.

## 3. Write it down

- `docs/work/<id>/spec.md`: the answers, in plain language, with the success number.
- Requirement rows, status `X`, in the area file, one per behaviour that can be tested.
- Decisions taken during grilling into `p1-closed-decisions.md`; questions the founder deferred
  into `p1-open-questions.md` with what each one blocks.

Show the founder the spec and rows; wait for their confirmation.

## 4. Gate and route

Run `skills/readiness-gate/`. When it passes, the orchestrator routes: `architect` (if data,
integration or a new surface), then `frontend-dev` (design and build) and `backend-dev` against the
contract, `qa`, and `legal` or `security` where step 2 pulled them in.