Define

A spec is the problem, scope, code, acceptance criteria and open decisions of one piece of work. It is done when someone who never saw the request could build it and know when it is finished.

Rules

• Follow project conventions. Take domain terms from the code and docs, and issue kinds and issue requirements from the tracker templates and contribution guidance.
• Start from the problem. Name who has the problem and what they cannot do today. A requested solution, such as "add a button", is one option, not the task.
• Read before you specify. Link every claim about the code at a commit. Mark what you could not check as an assumption.
• Ask, never pick. A choice that neither the request nor the code settles is a decision for the user or a maintainer: state the options and their trade-offs.
• Stop at the spec. Define does not build; it ends with a spec the user approves.

Flow

1. Read the request whole, comments included. Read a ticket from a PM, client or support as triage: non-technical says.
2. Check it is new. Search the tracker, open and closed, and the code and docs: it may already be supported, planned or rejected. If so, stop and report it. Skip what triage already checked.
3. Note the gaps: what the request leaves open about the problem, who has it, scope and constraints. Build on stated assumptions, and keep the questions for the review.
4. Map the code. Trace where the change lands: the entry points, the modules it touches, the nearby patterns to follow, and the behaviour that must not change. Assess design options with code-quality's design rules.
5. Specify. Write the acceptance criteria as Gherkin scenarios: the main path, then each edge and failure that matters. List the non-goals, the risks and the open decisions.
6. Size. One issue when the work is one outcome a reviewer can check. Otherwise split it at the size the user picks (create-issue: size), with a decision issue per open question; issues that reach one goal in order are a program (create-issue: programs).
7. Review. Show the spec with its questions, and the issue drafts the caller asked for, written with create-issue. When the spec adds acceptance a ticket lacks, show the whole edited body in a scratch file outside the tree. Wait for one approval, then publish what the user approves through the tracker's skill.

Output

<title>
Problem: <who cannot do what today>
Scope: <what changes>   Non-goals: <what does not>
Code: <entry points and modules, linked at a commit>
Acceptance:
```gherkin
<scenarios>
```
Risks: <what could go wrong> | none
Decisions: <question: options and trade-offs> | none
Assumptions: <claims not verified> | none
Size: one issue | <n> issues sized finding, pr or outcome | program of <n> issues sized finding, pr or outcome