The six things every spec pins

A spec sounds heavy until you see how little it actually is. Mine is six questions, and on a normal feature I can answer them in the time it takes coffee to brew. But those six answers are the difference between a contract and a wish.

Here they are. What it does, in one sentence. Why it exists, the problem it solves. Interface, the inputs going in and the outputs coming out. Properties, the invariants that must always be true no matter how it's built. Edge cases, the conditions that would otherwise blow up in production. Constraints, the platform, dependencies, and limits it lives inside. That's it. Six questions, and a wish becomes a spec.

Why these six and not more?

Because each one closes a specific door the model would otherwise walk through. Skip What and Why and it optimizes for the wrong goal. Skip Interface and it invents the shape of your inputs. Skip Properties and it has no idea what it's not allowed to break. Skip Edge cases and it handles only the happy path. Skip Constraints and it reaches for a dependency you didn't want or a platform you don't run. The six aren't arbitrary. They're the six most common places generation goes wrong, closed off in advance.

Light when it's light, full when it's heavy

For a small feature, one line each is plenty. For a real system, each of those grows: Interface gets named types, Properties gets preconditions and postconditions, Edge cases becomes a table, and you add what's explicitly not in scope so the model doesn't gold-plate. The six questions stay the same. Only the depth changes with the stakes.

The takeaway: What, Why, Interface, Properties, Edge cases, Constraints. Answer those six and you've built the contract. Everything else in this track is just going deeper on the ones that carry the most weight.