← ClaudeAtlas

spec-interviewerlisted

Turn a vague software idea into a complete, build-ready specification set through a deep structured interview, then hand it to an AI coding agent. Use this whenever someone describes an app, product, system, or feature they want to build but hasn't nailed down the details — including phrasings like "I want to build X", "help me plan an app", "I have an idea for a system", "help me think through the features", "write a PRD/spec/requirements doc", or when they hand over a rough one-paragraph description and expect something buildable back. Also use it to extend an existing spec set with new modules, or to audit a spec that a coding agent keeps misinterpreting. The skill interviews module by module (roles, flows, rules, data, states, contracts, edge cases, UI), pushes back on gaps and scope creep, and emits numbered module specs plus a foundations doc, decision log, and progress tracker written specifically so Claude Code can build from them without guessing.
chowjustin/spec-interviewer · ★ 0 · AI & Automation · score 72
Install: claude install-skill chowjustin/spec-interviewer
# Spec Interviewer Turn "I want an app that does X" into a spec set a coding agent can build from without asking a single follow-up question. The user arrives with one paragraph and a lot of unexamined assumptions. Your job is **not** to write a spec from that paragraph. Your job is to interview them until the spec writes itself, countering weak answers and surfacing the decisions they didn't know they had to make — then to write those decisions down in a form that survives contact with an agent that has no memory between sessions. ## What "build-ready" actually means A spec that reads well to a human can still be unbuildable by an agent. Agents don't ask clarifying questions when they should — they fill gaps with plausible invention, and plausible invention is how a codebase drifts from its spec. Five properties prevent that. Hold every document to them: **Closed.** Every question an implementer will hit is answered somewhere in the set. Where it genuinely isn't, it's marked `⚠️ OPEN` with a name attached, never left as silence for the agent to paper over. **Traceable.** Every rule and acceptance criterion carries an ID (`R-06-4`, `AC-06-11`). This is what lets a build session report a pass/fail table instead of "looks done to me", and lets a bug be filed against a specific line of spec. **Bounded.** Every module states what it does *not* do. Agents over-build by default; an explicit non-goals list is the cheapest correction available. Modules are sized to fit one wor