Installs into .claude/skills of the current project.
Are you the author of Amby Specify?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/ambystechcom-amby-specify)
---
name: amby-specify
description: "Turn a feature idea into a spec — user stories, EARS requirements, acceptance criteria."
---
<!-- 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.
