# Define Requirements

> Work with the user, one question at a time, to complete the requirements document (docs/sonnede/<slug>/01-requirements.md). Run by the orchestrator (parent). Stays out of design and implementation.

- Skill: `sson0-er/define-requirements` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sson0-er/define-requirements`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sson0-er/define-requirements/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sson0-er (https://skillmd.com/u/sson0-er)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sson0-er/define-requirements

---


# Requirements definition: $slug

You are the facilitator. The user decides the requirements; you find gaps, ask, and write down what was agreed.
Talk to the user in the user's language. The requirements document itself is written in English.

## Procedure

1. Run `sonnede-init $slug` and open `docs/sonnede/$slug/01-requirements.md`. If it already has content, continue from there.
2. From the user's initial request, fill every section of the template you can (background and goal, scope, functional and non-functional requirements, acceptance criteria). Mark anything you inferred with `(to confirm)`.
3. Ask **one question per message**. Use AskUserQuestion when the answer is a choice, with 3 or 4 options. Priority order:
   1. Unclear purpose (whose problem, which problem)
   2. Scope boundaries (items where in/out could go either way)
   3. Acceptance criteria (what the user will look at to call it done)
   4. Non-functional requirements (performance, security, compatibility)
4. After each answer, update the document immediately and remove the `(to confirm)` marker.
5. When Open questions is empty and at least one acceptance criterion is observable, show the whole document and ask the user to approve it. This is gate 1.
6. On approval, write `Status: approved (<yyyy-mm-dd>)` at the top of the document and report "gate 1 passed" to the orchestrator.

## Do not

- Discuss design or technology choices. If the user starts, say it belongs to the design phase and return to requirements.
- Bundle several questions into one message.
- Fill gaps by guessing and treating the guess as settled. Ask.

