/oma-brainstorm

name: oma-brainstorm
description: Explore goals, constraints, and alternative approaches before
  choosing a design. Use when the user requests ideation or design exploration.

Brainstorm - Design-First Ideation

Scheduling

Goal

Explore user intent, constraints, and alternative approaches before planning or implementation, then preserve an approved design for downstream planning.

Intent signature

• User says they have an idea, want to brainstorm, compare approaches, explore concepts, or design before planning.
• Request is ambiguous enough that implementation or task planning would be premature.

When to use

• Exploring a new feature idea before planning
• Understanding user intent and constraints before committing to an approach
• Comparing multiple design approaches with trade-offs
• When the user says "I have an idea" or "let's design something"
• Before invoking `/plan` for complex or ambiguous requests

When NOT to use

• Requirements are already clear and well-defined -> use `oma-pm` directly
• Implementing actual code -> delegate to specialized agents
• Performing code reviews -> use `oma-qa`
• Debugging existing issues -> use `oma-debug`

Expected inputs

• Early idea, ambiguous goal, product concept, design question, or set of constraints
• Existing project context when the idea must fit a codebase or product direction
• User preferences and approval gates

Expected outputs

• Clarified intent and constraints
• Two or three approaches as prose briefs (scenario, mechanism, residual risk) plus a comparison matrix and recommended option
• Section-by-section approved design document
• Blind-review issue list (Tier 1 resolved, Tier 2/3 resolved or explicitly deferred)
• Saved design artifact before handoff to planning

Dependencies

• Shared context loading, reasoning templates, clarification protocol, quality principles, and skill routing
• Optional `resources/triz-lite.md` for contradiction-shaped approach seeding
• Per-agent reviewer dispatch (e.g. `qa-reviewer`, `architecture-reviewer`) for the high-stakes blind-review escalation path
• Downstream PM workflow for task decomposition after design approval

Control-flow features

• Branches by ambiguity, user answers, approach comparison, and approval gates
• Optional TRIZ-lite branch when a technical/UX contradiction blocks distinct approaches
• Asks one question at a time
• Blind review round before save; may dispatch fresh-context reviewer subagents for high-stakes designs (the only subagent-spawning path in this skill)
• Stops before implementation or task planning

Structural Flow

Entry

1. Confirm that the request is exploratory rather than ready for implementation. 2. Load enough project context to understand constraints. 3. Start with intent and constraints, not solutions.

Scenes

1. **PREPARE**: Explore context and frame the design question. 2. **ACQUIRE**: Ask clarifying questions one at a time. 3. **REASON**: Generate two or three approaches with tradeoffs. 4. **VERIFY**: Get user approval section by section, then run a blind review round (independent lenses critique without seeing each other's feedback) before saving. 5. **FINALIZE**: Save design and transition to planning when appropriate.

Transitions

• If requirements become clear and implementation-ready, transition to PM planning.
• If user rejects an approach, revise before moving to detailed design.
• If implementation pressure appears early, defer it until design approval.
• If approaches collapse into knob-turning on one axis, load `resources/triz-lite.md` and reseed, then re-present prose briefs.

Failure and recovery

• If the user cannot answer a question, propose assumptions and ask for confirmation.
• If scope expands, split the design into smaller sections.
• If alternatives collapse into one option, identify the real constraint causing that; use TRIZ-lite only when that constraint is a technical/UX contradiction.

Exit

• Success: approved design exists and is ready for planning.
• Partial success: open questions and assumptions are explicit.

Logical Operations

Actions

| Action | SSL primitive | Evidence | |--------|---------------|----------| | Read context and idea | `READ` | User prompt and project context | | Ask targeted questions | `REQUEST` | Clarification phase | | Compare approaches | `COMPARE` | Tradeoff matrix | | Infer recommendation | `INFER` | Recommended option | | Emit option-selection decision | `CALL_TOOL` | `oma state emit` + `oma state verify --checkpoint option-selection` | | Validate approval | `VALIDATE` | Section-by-section confirmation | | Run blind review | `VALIDATE` | Independent lens critiques, tiered issue list, Tier 1 resolution | | Write design artifact | `WRITE` | `docs/plans/designs/` and memory | | Transition to plan | `NOTIFY` | Handoff summary |

Tools and instruments

• Context loading, reasoning templates, clarification protocol
• Optional TRIZ-lite resource for contradiction seeding
• Project memory and `docs/plans/designs/` for persisted designs

Canonical workflow path

1. Ask one clarifying question at a time.
2. (Optional) If technical/UX contradiction or same-axis approaches only → resources/triz-lite.md.
3. Present 2-3 approaches as prose briefs, then matrix, then recommendation; get user pick, then emit and verify the `brainstorm.option-selection` L1 decision.
4. Design section by section with user approval, then blind review: 4-8 independent lenses critique the design; resolve Tier 1 issues (fresh-context reviewer subagents for high-stakes designs).
5. Save the approved design to `docs/plans/designs/` before handing off to planning.

Resource scope

| Scope | Resource target | |-------|-----------------| | `MEMORY` | User intent, assumptions, decisions | | `CODEBASE` | Existing project context when relevant | | `LOCAL_FS` | Approved design artifacts; optional TRIZ-lite appendix in design doc |

Preconditions

• Th