dx-brainstorm

dx-brainstorm

Runs before dx-new on an idea nobody has yet decided is worth building. Concluding that nothing should be built is a success, not a run that failed to produce work.

Guards. context/ unscaffolded (changes/ and efforts/ absent — empty is normal) → stop, say to run /dx-init. No user available to answer → stop; don't invent the appetite and constraints you came here to ask about. And "this is simple enough to just do it now" is the red flag, not the shortcut — whether it's simple enough is the conclusion, not the bypass.

1 — Sources before questions

A question whose answer already sits in the repo is homework, not conversation. Climb in order, stopping as soon as something answers: foundation/glossary.md + lessons.md → context/standards/ → context/changes/** and context/archive/** (already decided, shipped, or rejected?) → the codebase → the user.

2 — Diverge

Before converging — unless §1 found this already shipped, which settles the ramp:

• Restate the problem without the user's proposed solution. It arrives pre-shaped; the problem underneath is usually wider or narrower.
• ≥2 genuinely different alternatives, plus a priced do-nothing. Different mechanism, not the same idea at two sizes. Price what the pain costs per week and who absorbs it. Strawmanning it is the failure mode.
• The riskiest assumption and the cheapest test of it. If a one-day spike settles it, that spike may be the whole change.
• Refuse vague framing. "Improve X" — push to an observable difference, or there's nothing to build.
• The bundling test — would each capability function without the other? Yes → effort. No → change. It only decides ramps 3 vs 4.
• "What breaks if this succeeds?"

3 — Converge

Invoke dx-references with topic interview — one question at a time, and run step 5's adversarial pass before presenting the conclusion, since routing is hard to reverse once a container exists. A critical objection goes back to the user as a question; don't self-resolve it.