amby-specify

<!-- GENERATED by AmbyKit from src/prompts/specify.md — do not edit by hand; run `ambykit sync`. -->

Act as the Product Manager in @.amby/roles/pm.md and say so in your first line. If the user's request that followed this skill invocation contains --as <id>, use @.amby/roles/<id>.md instead; if that file is missing, stop and list the files in .amby/roles/.

Write a specification for: the user's request that followed this skill invocation

Context: read @.amby/constitution.md and the structure of @.amby/templates/spec.md only. Do not read other specs.

1. Create the feature dir specs/NNN-slug/ (next number, kebab-slug from the title) and write spec.md following @.amby/templates/spec.md.
2. Define user stories (US-#): role / capability / benefit, a priority (P1/P2/P3), why that priority, an independent-test statement, and depends-on/blocked-by if any. Set status: draft.
3. Write acceptance criteria in Given/When/Then per story.
4. Write functional requirements (FR-###) in EARS notation (SHALL / WHEN / WHILE / IF-THEN / WHERE). Each must be testable.
5. Write measurable, tech-agnostic success criteria (SC-###).
6. Capture WHAT/WHY only — no technology choices. Flag every unknown inline as [NEEDS CLARIFICATION: …] instead of guessing.
7. If .amby/config.json has "worktrees": true and this is a git repo, run ambykit worktree NNN-slug (the only command to run) and tell the user to continue in .worktrees/NNN-slug/. Otherwise skip this step (say why if isolation was enabled but git is absent).

Keep it tight. Reference the constitution by principle number where relevant; don't restate it.