Intent Storming — the practice you run before you write code

The problem: teams jump from idea to code

With capable models, it is tempting to go straight from an idea to prompts to running code. It works for an afternoon. Then six weeks later nobody remembers why a trade-off was made, the agent has quietly drifted onto a different problem, and the spec — if one was written — describes a system that no longer exists. The why and the what-to-achieve were never structured, so there was nothing for the work to stay anchored to.

The proposal: make intent the first deliverable

We propose treating Intent Storming as an explicit, named step at the start of a piece of work — the same way teams already treat a kickoff or a design review. The deliverable of that step is not a document to be filed; it is a navigable intent tree (Purpose / User Context / Means) that every later slice will inherit from. Fixing intent before code is the cheapest place to remove drift, because nothing has been built on top of the wrong assumption yet.

Two shapes: a group workshop, or solo with the AI

As a workshop, the product owner and engineers sit together (designers too, if the surface matters) and answer the questions the tree expects: why does this exist, who is it for, what does the MVP have to do, what trade-offs are we already willing to make? Or it runs solo: one person acts as the product owner while the AI interviews them — for each open decision it lays out background, options, the pros and cons of each, and a recommendation, then asks. Either way you are the product owner being interviewed, and the answers land directly in the tree as Purpose / User Context / Means nodes.

How a session goes

1. State the goal and the architecture in plain language, as a product owner would — what we are building, why, and the stack and constraints we already know.
2. The AI turns it into a structured interview: per open decision, background → options → pros and cons → recommendation, then a question. You answer only where you have a strong opinion and accept the recommendation everywhere else.
3. Answers are written straight into the tree as Purpose / User Context / Means nodes, with promotion states (inferred → clarified → canonical) keeping confidence explicit.
4. You stop when the tree is fixed at the granularity that matters — from a single screen element up to the broadest concept. You can start from a small set of key points and add stricter intent later where it must be honored.

Honest scope: this needs a product owner with judgment

This is not "no technical skill required." Choosing the stack, judging the options the AI lays out, and recognizing when the intent has drifted all need real engineering and product judgment. The encouraging flip side, which we have seen in practice: a technically capable person with no prior tooling experience can assemble solid, structured intent on the very first run — because the method is carried by the guidance and the thinking is carried by their own AI. Intent Storming raises the ceiling for someone who has judgment; it does not remove the need for it.

"Don't start by writing code. Start by becoming the product owner — and let the work walk out as a tree of intent." Run Intent Storming first; let everything downstream inherit from it.

Independent of any product

Intent Storming is a practice, not a feature. You can run it with whatever AI you already use and a plain folder of markdown files for the tree. It is embodied in Intent-System — where intent-cli supplies the interview structure and the tree format — but the practice itself stands on its own, upstream of whatever toolchain you build with.