Oma Brainstorm Agent Skill

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 pm-agent directly
• Implementing actual code -> delegate to specialized agents
• Performing code reviews -> use QA Agent
• Debugging existing issues -> use debug-agent

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 with tradeoffs and a recommended option
• Section-by-section approved design document
• Saved design artifact before handoff to planning

Dependencies

• Shared context loading, reasoning templates, clarification protocol, quality principles, and skill routing
• Downstream PM workflow for task decomposition after design approval

Control-flow features

• Branches by ambiguity, user answers, approach comparison, and approval gates
• Asks one question at a time
• Stops before implementation or task planning

Structural Flow

Entry

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

Scenes

• PREPARE: Explore context and frame the design question.
• ACQUIRE: Ask clarifying questions one at a time.
• REASON: Generate two or three approaches with tradeoffs.
• VERIFY: Get user approval section by section.
• 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.

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.

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 |

| Validate approval | VALIDATE | Section-by-section confirmation |

| Write design artifact | WRITE | docs/plans/designs/ and memory |

| Transition to plan | NOTIFY | Handoff summary |

Tools and instruments

• Context loading, reasoning templates, clarification protocol
• Project memory and docs/plans/designs/ for persisted designs

Canonical workflow path

1. Ask one clarifying question at a time.
2. Present 2-3 approaches with tradeoffs and a recommended option.
3. 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 |

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

• No implementation or planning before design approval - brainstorm produces a design document, not code or task plans
• One question at a time - ask clarifying questions sequentially, not in batches
• Always propose 2-3 approaches - include a recommended option with trade-off analysis
• Section-by-section design - present design incrementally with user confirmation at each step
• YAGNI - do not over-engineer; design only what is needed for the stated goal
• Save design, then transition - persist the approved design document before handing off to /plan

Execution Phases

Follow the brainstorm workflow step by step:

• Phase 1 - Context: Explore the existing codebase and understand the project landscape
• Phase 2 - Questions: Ask clarifying questions one at a time to understand intent and constraints
• Phase 3 - Approaches: Propose 2-3 approaches with a recommended option and trade-off matrix
• Phase 4 - Design: Present the detailed design section by section, getting user approval at each step
• Phase 5 - Documentation: Save the approved design to docs/plans/designs/ and project memory
• Phase 6 - 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: Presenting only one option without alternatives
• Over-engineering: Designing for hypothetical future requirements instead of stated needs
• Skipping confirmation: Moving forward without explicit user approval on design decisions

References

Vendor-specific execution protocols are injected automatically by oma agent:spawn.

Source files live under ../_shared/runtime/execution-protocols/{vendor}.md.

• Context loading: ../_shared/core/context-loading.md
• Reasoning templates: ../_shared/core/reasoning-templates.md
• Clarification protocol: ../_shared/core/clarification-protocol.md
• Quality principles: ../_shared/core/quality-principles.md
• Skill-to-agent mapping: ../_shared/core/skill-routing.md