/sketch
Some questions answer only to running code. /sketch builds the smallest throwaway that answers one design question — then guarantees it never leaks into the product.
Preconditions
- Exactly one design question, named. "Does this state model feel right when driven?" is one question. "Should we use this stack and how should the UI look?" is two sketched projects and a meeting — refuse, split, come back. A question that facts could answer is
/scout; one that weighing could answer is /grill.
- The question survives cheapness. A sketch is minutes-to-an-hour, not days. Bigger than that is a prototype ticket, not a sketch.
How to sketch
- Write the question at the top of the sketch's own README — the sketch exists to answer it and nothing else.
- Build the least code that makes the question answerable in
.sketches/<slug>/ — no tests unless the question is about tests, no polish, no structure beyond the question's need.
- Drive it. Interact with it, feed it data, watch the behavior the question asked about.
- Write the verdict in the sketch README: the answer, plainly, with what surprised you. The verdict travels back to the conversation — and into
/spec's Implementation Decisions when it settles something; a compact fragment may travel with it, trimmed to the decision it carries.
- Dispose deliberately. The sketch is never merged — anything worth keeping is a deliberate rewrite into the real codebase, never a copy from the sketch. Ending state is a choice stated aloud: delete now, or keep archived as reference; either way it stays out of every branch that matters.
Response shape