speclisted

# /spec ## Goal Turn a fuzzy request into two committed artifacts — a **spec** (what/why) and a **plan** (how, in waves) — before any implementation edit, then hand the plan to the user for approval. Approval is what unlocks editing: `plan-gate.py` writes the plan-approval flag, and `spec-gate.py` (a PreToolUse gate) stops asking once that flag exists. This skill supplies the *methodology*; the *enforcement* is a tool boundary. You cannot prompt your way past `spec-gate` — you produce the artifacts and get the plan approved, or you flip the mode. That separation is the point. ## Steps ### 1. Brainstorm Explore the request before committing to a shape: a. Restate the request in one sentence and name the success criterion. b. Surface the 2-3 plausible approaches and the tradeoff between them; pick one and say why. If the request is ambiguous, ask — don't guess. c. List what's explicitly **out** of scope (prevents scope creep later). #### `--interview` — opt-in deep-interview submode The default brainstorm is a single pass. `/spec <slug> --interview` replaces step 1b's one-shot "ask if ambiguous" with a structured question loop for requests fuzzy enough that a wrong guess commits the whole spec to the wrong shape. It is opt-in by design: simple requests keep the single pass, and the enforcement story is untouched — the spec-gate tool boundary neither knows nor cares which submode produced the artifacts. 1. **Unknowns table.** List every unknown in the request; mark