speclisted

Turn an abstract idea into a detailed specification. ## Role separation: /spec vs /plan | Aspect | /spec | /plan | |--------|-------|-------| | Input | Vague idea, abstract prompt | Clear spec, defined task | | Focus | **What** to build (requirements, constraints) | **How** to build (implementation strategy, files) | | Output | Spec doc (`docs/specs/*.md`) / GitHub issue | Implementation plan (`docs/plans/active/*.md`) | | Research | Codebase exploration, web search, best practices | Affected files, risk analysis | | User interaction | Decision-tree questioning with recommended answers + clarification | Flow selection (standard/Ralph) + critical-fork resolution (convergent) | `/spec` comes before `/plan`. Use `/spec` when the request is too vague for `/plan`. ## Goals - Transform ambiguous requests into implementation-ready specifications - Expand sparse inputs (even a one-line prompt) through decision-tree questioning with recommended answers - Discover requirements through codebase analysis and best-practice research - Resolve residual ambiguity through targeted user questions - Produce a versioned spec that survives context loss - Isolate every temporary or versioned spec artifact in a clean-base task worktree before writing it ## Steps 1. **Understand the request** (internal, no user interaction): Read the user's input. List what is clear and what is ambiguous or missing. This is an internal triage step — do NOT call `AskUserQuestion` here. The list feeds the nex