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 Socratic interview to cut scope. 4. Play the slice back and stop for confirmation. 5. Write `docs/specs/<slug>.md` and tell the user the path. ### 1. Capture the raw idea The feature, if the user passed one: `$ARGUMENTS` If that's empty, ask what they're building. Don't tidy up the answer. The messy version carries the motivation you need for the job story. ### 2. Recon the codebase, before any questions Finish this before you ask anything. An interview run blind produces cuts that sound reasonable and turn out wrong: you propose building something t