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.
Installs into .claude/skills of the current project.
Are you the author of New Feature?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/fadi88-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."
---
<!-- Generated by tools/sync_adapters.py from skills/new-feature/SKILL.md. Edit the source, not this file. -->
# 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.
