Pre-Pipeline Requirements Brainstorm

Interview the engineer and write {module}/intent/brainstorm.md, one way to produce the intent document the pipeline starts from. Run in your own session, before the pipeline — this conversation never enters the pipeline's context, and you write no result.json.

The document is frozen once a run starts, so a requirements change is a fresh invocation of this skill, never an edit to an in-flight artifact. Re-invoked that way, the existing document is your input: what is left to ask is what the change unsettles, and you say in the document which parts this round did not touch.

Where the output goes

{module} is any path the engineer wants — the same one the pipeline is later given as --module. If they named only a module, ask; do not invent a parent, or you send them looking for a tree they did not ask for.

Create {module}/intent/ and put the document in it, along with anything the engineer delivers that it names as authoritative — a reference model, a register map, a standard. That directory is the whole of what the pipeline treats as intent: a file left at the module root is handed to no stage and recorded by no proof.

The dialogue

What is left to ask is whatever the material the engineer brought does not already settle. Someone arriving with a protocol standard and a register map has settled their interfaces and clocking; asking again spends the only thing this dialogue costs.

It is done when none of these is still unspoken for: intent and scope · functions and features · top-level IO, and inter-module wires when N>1 · clocks, resets, and every crossing between them · architecture partition · timing scenarios · PPA targets · readiness. What each one contains you can work out; whether this project has settled it, you cannot.

One question at a time, and end each with the answer you would give and why — a question with no recommendation makes the user do your work. Where the partition is still open, put 2-3 candidates side by side so they choose rather than inherit your first idea.

On readiness, ask whether the stages that author from this document could do so without coming back, and name every gap you find.

Four things this dialogue is the last chance to settle

• A number a reference implementation would answer — a latency, a byte width, a state-machine cycle count. Settle it here with its source. Deferred, it reaches design.md as a wrong first draft and a run of Edits on the main thread.
• Reset polarity, and sync vs async — deferred, it becomes an SDC-stage guess.
• What is deliberately left unconstrained — a PPA dimension with no bound, a behaviour left to the implementer, a bound some outside authority owns. Say which: the ledger has a judge for each of those, and none for a silence it cannot read.
• Every open question — resolve it before the document is frozen where possible. Any remaining requirement gap becomes a human-judged ledger row for clarification.

The document, and handing it off

Keep the engineer's own document when they brought one, including the context and referenced sources needed to interpret it. specification identifies obligations and organizes the ledger by what must be judged, preserving their meaning, conditions and scope.

Re-read what you wrote and fix inline anything that would survive the freeze: a placeholder, a two-way-ambiguous requirement, a contradiction between two parts of the document, or between the document and a file it cites as authoritative.

Then hand over the path and a short orientation — the areas covered, and on a revision, which ones changed. Do not echo the document body. Then stop: nothing is dispatchable until that file exists, and starting the pipeline is how the engineer says it is right.