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
- Viable approaches as prose briefs (scenario, mechanism, residual risk), with comparison and recommendation when alternatives aid the decision
- 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**: Compare viable approaches with tradeoffs when alternatives aid the decision; explain binding constraints when only one remains.
4. **VERIFY**: Reuse existing design authority and resolve only material open choices, 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 |
| Record option selection | `CALL_TOOL` | Actual approach, comparison evidence, and design/option revision; matching `instanceId` and verifier `--instance` in an active OMA workflow |
| Resolve design authority | `VALIDATE` | Existing instruction, delegated choice, or explicit answer for an unresolved material design choice |
| 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
```text
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 viable alternatives as prose briefs and compare them when useful; do not invent extra options to meet a count; reuse an existing selection or delegated choice and resolve only an open material choice. In an active OMA workflow, record the actual approach, rationale, evidence, and design/option revision with `brainstorm.option-selection`; verify the matching --instance (workflow Step 3 owns the commands).
4. Design section by section within existing authorization, then blind review: independent lenses suited to the uncertainty and stakes 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
- The user is still exploring or the request is ambiguous.
- The agent can ask clarifying questions before implementation.

### Effects and side effects
- Produces design decisions and persisted design docs.
- Influences downstream planning but does not implement code.

### Guardrails
1. **No implementation or planning before design approval** - brainstorm produces a design document, not code or task plans
2. **One question at a time** - ask clarification and approval questions through the available asynchronous question tool first, following `../_shared/core/clarification-protocol.md`; fall back to a permitted question tool or plain text. Continue independent work while waiting, and never infer approval from silence or a preselected option.
3. **Compare viable approaches** - offer two or three when they aid the decision, and explain constraints when fewer remain. Recommend according to the actual goal, effort, reversibility, and risk. Do not favor a larger structural change solely because of its label.
4. **Explain viable approaches in prose** - state scenario, mechanism, residual risk, and effort. Use a comparison matrix when it helps the decision, then give the recommendation; a single constrained option needs its rationale, not invented alternatives
5. **Section-by-section design** - present the design incrementally; reuse existing decisions and delegated authority, asking only for unresolved material choices under the shared execution policy
6. **Blind review before save** - mandatory unless the design is trivially small (1-2 files, low stakes); lenses critique independently; use fresh-context reviewer subagents for architecturally significant, hard-to-reverse, or security-/compliance-sensitive designs
7. **YAGNI** - do not over-engineer; design only what is needed for the stated goal
8. **TRIZ-lite is optional** - only for technical/UX contradictions or same-axis collapse; max 3–5 principles from the curated set; no fake scores, full TRIZ/ARIZ, or classical matrices; seeds feed Step 3 briefs and do not replace user approval
9. **Save design, then transition** - persist the approved design document before handing off to `/plan`

### Execution Phases
Follow the brainstorm workflow step by step:
1. **Phase 1 - Context**: Explore the existing codebase and understand the project landscape
2. **Phase 2 - Questions**: Ask clarifying questions one at a time to understand intent and constraints
3. **Phase 3 - Approaches**: Optionally seed with TRIZ-lite for a real contradiction; compare viable approaches in prose and recommend according to the stated constraints, effort, reversibility, and risk
4. **Phase 4 - Design**: Present the detailed design section by section, preserving existing authorization and resolving only open material choices
5. **Phase 5 - Blind Review**: Use independent reviewer lenses proportionate to the design uncertainty and stakes, consolidate into Tier 1/2/3 issues, resolve Tier 1 before save; escalate to fresh-context reviewer subagents for high-stakes designs. Skip only for trivially small designs (1-2 files, low stakes)
6. **Phase 6 - Documentation**: Save the approved design to `docs/plans/designs/` and project memory
7. **Phase 7 - Transition**: Hand off to `/plan` for task decomposition

### Common Pitfalls
- **Jumping to solutions**: Asking "how" before fully understanding "what" and "why"
- **Too many questions at once**: Overwhelming the user with a wall of questions
- **Single approach bias**: Skipping viable alternatives without explaining binding constraints
- **Matrix-only options**: Dumping a trade-off table without scenario/mechanism prose so the user cannot choose
- **Same-axis "alternatives"**: Three intensities of the same knob (interval/TTL/debounce) presented as distinct approaches
- **TRIZ on everything**: Loading triz-lite without a real contradiction, adding ceremony without better options
- **Over-engineering**: Designing for hypothetical future requirements instead of stated needs
- **Inventing design authority**: Treating an agent recommendation as approval of a user-owned unresolved choice, or asking again for a choice already authorized
- **Skipping blind review**: Saving a non-trivial design without the independent critique round, or letting the design's author-context leak into escalated reviewer prompts

## References
- TRIZ-lite (optional Step 3 seeding): `resources/triz-lite.md`
- Context loading: `../_shared/core/context-loading.md`
- Clarification protocol: `../_shared/core/clarification-protocol.md`
- Quality principles: `../_shared/core/quality-principles.md`
- Skill-to-agent mapping: `../_shared/core/skill-routing.md`