brainstorm

Invoke the brainstorm skill with an optional card ref, such as /brainstorm RLY-42. It asks clarifying questions one at a time, proposes 2-3 approaches with trade-offs, and presents the design in sections for your approval before any implementation starts.

The approved spec is written to the Relay card using ./bin/relay spec <ref> @<tmpfile>, never to a shared docs directory. Acceptance criteria are written in the same step with ./bin/relay criteria <ref> @<tmpfile>.

Yes, headless mode batches all clarifying questions into a single structured needs-input call with a JSON question array, then stops. When the human answers, the card returns and the skill writes the spec and acceptance criteria.

Each criterion is numbered with numbered action steps ending in one observable expectation, such as a visible UI state. Criteria must be concrete, executable from a cold start, and describe user-observable behavior rather than implementation details.

Matching a mockup is a deliberate per-feature decision, never a default, because artboards drift from the shipped app. The spec must explicitly name the artboard file and the elements or states to match, or record a deliberate no-mockup decision.