specifylisted

# Specify Turn approved intent into a lintable, testable SpecScore Feature. ## Hard Gate <HARD-GATE> Do NOT invoke `writing-plans`, `frontend-design`, `mcp-builder`, or ANY implementation skill until ALL of the following are true: 1. The Feature artifact exists at `spec/features/<slug>/README.md` and contains at least one `#### REQ: <slug>` requirement inside the `## Behavior` section. 2. Each requirement has ≥1 acceptance criterion in `Given / When / Then` format. 3. `specscore spec lint` passes. 4. The reviewer gate has released — every entry in `gates.specify.reviewers` (including the `type: human` entry that captures the user's approval) returned `Approved` per the [reviewer-gates](../../spec/features/reviewer-gates/README.md) Feature's AND-composition. This applies to **every** Feature, regardless of perceived simplicity. The only skills invoked after `specstudio:specify` are `writing-plans` (Plan) or `specstudio:implement` (Implement), as chosen by the user at the transition menu. </HARD-GATE> ## When to Use - A SpecScore Idea is `Approved` and ready to become a Feature. - User has a clear, high-conviction buildable intent (may skip `specstudio:ideate`). - Behavior of an existing Feature needs to change — **revise in place** (see [path-conventions.md](../shared/path-conventions.md)). ## Anti-Pattern: "This Is Too Simple To Need A Spec" Every Feature goes through this. A toggle, a one-line config, a single utility — all of them. Simple Features are where