slicelisted

# Full-stack slice SPEC A full-stack slice cuts vertically through every layer a feature needs: storage, logic, interface, integration. It ships on its own, and a user gets something they couldn't get before. The opposite is a horizontal slice ("add the schema", "build the API", "design the UI"), which ships nothing anyone can use and hides the integration pain until the end. Full stack means whatever this project's fullest stack is. For a web app, storage through to screen. For a CLI, argument parsing through to printed output. Let the repo tell you its layers instead of assuming. The job is finding the version that costs a fraction of the work and is still worth shipping. The SPEC goes to a session that has none of this conversation, so it has to stand alone. ## Workflow 1. Capture the raw idea in the user's words. 2. Recon the codebase with subagents. Wait for them; the interview depends on what they find. 3. Run the interview to cut scope. 4. Fill in the SPEC template and paste the whole thing in a message for review. This is the skill's only approval gate. 5. Write the approved draft to `docs/specs/<slug>.md` and tell the user the path. **The gate is the SPEC text, and it is the only gate.** Never end a turn with a prose recap of the slice and "confirm and I'll write the SPEC" — that asks the user to approve something they haven't read, which is the whole problem. If you're about to send that message, send the draft instead. And before writing the file, check one t