| name | brainstorming |
| description | Use when a user asks to create a feature, change behavior, design a workflow, or build a product and the desired design has not been explicitly approved. Clarifies intent one question at a time before implementation. |
| activation | new behavior without an approved design. |
| required_inputs | User outcome, relevant project context, constraints, non-goals, and success signal. |
| required_outputs | Approved design record or Blocked decision, followed by a writing-plans handoff. |
| authority_dependencies | 00_start_here/SOURCE_OF_TRUTH.md; 10_governance/APIVR_EXECUTION_LIFECYCLE.md; 10_governance/source_of_truth/Elite_Build_Goals_v3.md. |
| evidence_requirements | Directly inspected context and user-approved design, or an honest Blocked state. |
Brainstorming Into an Approved Design
Use this before implementation work when the user has an outcome but not a
decision-complete design. The design can be short. It cannot be assumed.
Hard Gate
Do not scaffold, edit production code, select a provider, or write an
implementation plan until a design has been presented and approved, unless the
user already supplied a decision-complete design or explicitly directs a narrow
reversible experiment.
Workflow
- Inspect only the project context needed to avoid asking questions already
answered by source, tests, or recent decisions.
- Ask one focused question at a time. Prefer an answerable choice when it
reduces ambiguity. Cover user, outcome, constraint, non-goal, and success
signal.
- If the request contains independent systems, split it into the first
vertical outcome. Do not design a whole platform as one task.
- Present two or three viable approaches with trade-offs and a recommendation.
- Present the proposed design: boundary, data or control flow, failure state,
evidence plan, and rollback point. Request approval.
- Save the approved design in the project’s canonical docs location, scan for
contradictions and placeholders, then load
writing-plans.
Design Record
## Decision
- User outcome:
- In scope / non-goals:
- Chosen approach and rejected alternative:
- Interfaces and data flow:
- Failure and recovery behavior:
- Success measure and verification horizon:
Worked Example
Request: “Add a way for users to export campaign results.”
Ask first: “Should the export be a live CSV of the current filters, or a saved
scheduled report? I recommend a live CSV first because it solves the immediate
download need without introducing a job queue or email delivery.”
After approval, record that the first slice is a filtered CSV response, with
authorization and empty-state behavior. Then hand off to writing-plans; do
not begin route code during brainstorming.
Failure Paths
- If the user declines the design, revise the decision record, not the code.
- If a required owner, data definition, or success condition is unknown, mark
the design
Blocked and ask the one question that resolves it.
- If the user asks for a prototype, isolate it and label what it cannot prove.
