---
name: stdd-brainstorming
description: "Explore future behavior and hypothetical approaches without forcing action. Use when: Asked for opinions, ideation, future behavior, or a hypothetical implementation approach, with no explicit intent to persist or modify the repository."
---

<!-- generated by stdd plugin build v0.11.0 — do not edit -->


# Brainstorming

Use Brainstorming as an adaptive conversational stance, not a fixed interview.
The goal is useful clarity about **what** and **why** before anyone commits to
action. Clarity, deciding not to act, and continuing later are all successful
outcomes.

## Contract

- Stay read-only: create no task, ledger event, persisted artifact, or
  repository mutation.
- Ground the discussion in current docs or code when materially useful. If
  unknown current facts materially affect the design, invoke
  `stdd-investigation` first; ordinary reading here is not Investigation.
- A hypothetical plan shown in chat remains Brainstorming. Explicit intent to
  persist an artifact or modify the repository crosses into Start Change when
  no action boundary is active. Within an active change, do not invoke Start
  Change again; proceed to Planning or Implement as the agreed action requires.

## Conversation

1. **Understand the real need.** Let the user provide context in their own
   shape. Challenge assumptions and decompose ideas that are larger than the
   need; apply YAGNI rather than rewarding scope.
2. **Ask only decision-bearing questions.** Ask at most one per turn, and only
   when its answer is needed to proceed. Prefer a concise closed choice when
   the answer space is known. Use a question batch only when the user requests
   one.
3. **Offer useful alternatives.** Once context is sufficient, present two or
   three materially distinct approaches, state the trade-off that matters, and
   lead with a recommendation. Do not manufacture alternatives when only one
   approach is sensible.
4. **Validate incrementally.** Check substantive decisions as they emerge
   instead of withholding all validation for a final ceremony. An optional
   recap may state the problem, preferred approach, and unresolved questions.

## Outcomes

Follow the user's intent without forcing a three-option menu:

- **No action:** summarize if useful, then stop. Do not pressure the user to
  formalize or implement anything.
- **Defer:** leave a portable backlog note in chat. Persist it only when the
  user explicitly chooses a destination; if no action boundary is active,
  invoke `stdd-start-change` before writing it.
- **Act now:** when the user explicitly chooses persisted or
  repository-changing action, invoke `stdd-start-change` if no action boundary
  is active. Within an active change, proceed directly to Planning or Implement
  as appropriate.

## Anti-patterns

- Turning exploration into a mandatory interview or checklist.
- Asking stacked questions when one decision would unlock progress.
- Jumping into code or artifact creation without explicit action intent.
- Treating every conversation as a change that must converge on docs, a plan,
  or a PR.
- Presenting options without an opinion, or inventing options to satisfy a
  quota.