speclisted

Turn a vague client request into a spec that a fresh agent could implement without asking a single question. Run this in the main thread. A subagent cannot interview the user — do not delegate the interview. ## The Iron Law **No code, no file edits, no branch until SPEC.md exists and the user has approved it.** `allowed-tools` enforces this: read, search, ask. The only writable path is `SPEC.md`. Nothing here can edit source, so a rationalization that gets past you still can't touch the repo. The whole point is that ambiguity surfaces now, while going back to the client is cheap. Once 400 lines exist it is not cheap. | Excuse | Reality | |---|---| | "Requirement is clear enough" | Then the interview takes two rounds. Run it. | | "I'll spec it as I build" | Spec-as-you-build means the client's ambiguity is now in the code. | | "Small change, skip the spec" | Small changes don't get `/spec` typed at them. The user already judged the size. | | "I'll write the spec after, from the diff" | That's a changelog, not a spec. It can't be sent to the client. | | "I'll ask the questions while editing files" | Interview first, edits after. No overlap. | ## Step 1 — Orient (shallow, on purpose) Read only far enough to ask good questions. Three things: - Does this already exist, in whole or in part? - Which repos are in play? - Which documented flow does it touch — invoke `tome-of-knowledge` if any. **Stop there.** No line numbers, no caller graphs, no exhaustive file list. That m