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.
- Create the feature dir
specs/NNN-slug/(next number, kebab-slug from the title) and writespec.mdfollowing@.amby/templates/spec.md. - Define user stories (
US-#): role / capability / benefit, a priority (P1/P2/P3), why that priority, an independent-test statement, anddepends-on/blocked-byif any. Setstatus: draft. - Write acceptance criteria in Given/When/Then per story.
- Write functional requirements (
FR-###) in EARS notation (SHALL / WHEN / WHILE / IF-THEN / WHERE). Each must be testable. - Write measurable, tech-agnostic success criteria (
SC-###). - Capture WHAT/WHY only — no technology choices. Flag every unknown inline as
[NEEDS CLARIFICATION: …]instead of guessing. - If
.amby/config.jsonhas"worktrees": trueand this is a git repo, runambykit 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.