SKILL.md
$27
"1. GROUND" [style=filled, fillcolor="#e8e8ff"];
"2. DIVERGE: Problem" [style=filled, fillcolor="#ffe8e8"];
"3. CONVERGE: Define" [style=filled, fillcolor="#e8ffe8"];
"4. DIVERGE: Solutions" [style=filled, fillcolor="#ffe8e8"];
"5. CONVERGE: Decide" [style=filled, fillcolor="#e8ffe8"];
"EXIT → Any skill" [style=filled, fillcolor="#fff8e0"];
"1. GROUND" -> "2. DIVERGE: Problem";
"2. DIVERGE: Problem" -> "3. CONVERGE: Define";
"3. CONVERGE: Define" -> "4. DIVERGE: Solutions";
"4. DIVERGE: Solutions" -> "5. CONVERGE: Decide";
"5. CONVERGE: Decide" -> "EXIT → Any skill";}
---
## Phase 1: GROUND (Memory-First)
Lean on existing knowledge before generating new ideas. The cost of a Sibyl search is low; the cost of re-discovering a pattern we already learned is high.
### Common moves
- **Search Sibyl** for related patterns, decisions, and known constraints. Useful queries: `sibyl search "<topic keywords>"`, `sibyl search "<related architecture>"`, plus a quick scan of existing tasks/epics on the topic.
- **Surface constraints** that aren't up for debate: tech stack locks, budget, timeline, conventions you'd be foolish to violate.
- **Present prior art** before ideating: "Sibyl has 3 relevant entries: [pattern X], [decision Z], [gotcha W]. Want to factor these in?"
If Sibyl already has a directly applicable answer, surface it first. The brainstorm is then about whether to apply it as-is, adapt it, or genuinely diverge, not re-deriving it from scratch.
---
## Phase 2: DIVERGE: Explore the Problem Space
**Goal:** Generate breadth. Understand what we're actually solving before reaching for solutions.
### Common moves
- **Lean toward one load-bearing question at a time.** Stacking five questions buries the signal; building understanding incrementally surfaces what actually matters. The exception is when the user fires multiple parallel asks; then answer them in parallel rather than artificially serializing.
- **Reframe the problem** from multiple angles: user view ("as a [user], I need..."), system view ("the system currently..."), constraint view ("we're bounded by...").
- **Spawn parallel Explore agents** when the problem space is genuinely large: research how similar projects solve this, map the existing codebase surface, search for SOTA approaches.
The discipline here is staying in problem space when the pull toward solutions is strong. If the problem is already crisp, skip ahead. This phase exists to prevent solving the wrong thing, not to perform exploration.
### Anti-patterns
- Jumping to solutions before the problem frame is clear
- Stacking questions when the answers depend on each other
- Dismissing vague input ("make it faster" is a valid starting point; help sharpen it instead of rejecting it)
---
## Phase 3: CONVERGE: Define the Core Problem
**Goal:** Narrow from exploration to a crisp problem statement before exploring solutions for it.
Synthesize the exploration into a 1-2 sentence problem statement, confirm it lands ("is this what we're solving?"), and call out scope boundaries. The output usually looks like:
> **Problem:** [crisp statement]
> **In scope:** [what we'll address]
> **Out of scope:** [what we won't]
> **Key constraint:** [the most important limiting factor]
If the problem was already crisp coming in, this phase is a 30-second confirmation, not a deliverable.
---
## Phase 4: DIVERGE: Explore Solutions
**Goal:** Generate multiple viable approaches with explicit tradeoffs.
### Common moves
- **Present 2-3 approaches** with tradeoffs side-by-side. Two is the floor (otherwise it's a recommendation, not a brainstorm); past four, decision fatigue kicks in.
| Approach | Pros | Cons | Complexity | Risk |
| --------- | ---- | ---- | ------------ | ---- |
| A: [name] | ... | ... | Low/Med/High | ... |
| B: [name] | ... | ... | Low/Med/High | ... |
| C: [name] | ... | ... | Low/Med/High | ... |
- **Include one unconventional option** when the obvious paths look similar. Fixation on the first decent idea is the failure mode this phase is designed to prevent.
- **Ground in existing patterns:** "this follows what we did in [project X]" or "this diverges from our convention because [reason]".
- **Name the verification method** for each approach so the choice connects to a concrete check (test, benchmark, visual confirmation).
### Exploration vs exploitation
Balance like MCTS. Don't fixate on the first decent idea:
- If all approaches look similar → push for a wild card option
- If approaches are wildly different → that's healthy divergence
- If the user gravitates early → present the contrarian case before converging
### Anti-patterns
- Seven "maybe" options instead of 2-3 real choices with tradeoffs
- Options presented without explicit costs (every option has one)
- Options that quietly violate constraints surfaced in Phase 1
- Defaulting to the most complex solution; start simple, add complexity only when justified
---
## Phase 5: CONVERGE: Decide and Record
**Goal:** Lock in the approach, record the decision, exit to action.
The user picks. Present your recommendation with conviction but don't bulldoze; the whole point of divergent exploration is preserving genuine choice. Then record the decision in Sibyl so future sessions don't re-litigate it:sibyl add "Brainstorm: [topic]" "Chose [approach] because [reason]. Rejected [other approaches] due to [tradeoffs]. Key constraint: [X]."
Hand off to whatever's next:
| Next Step | When |
| -------------------------- | ------------------------------------- |
| `/hyperskills:plan` | Complex feature needing decomposition |
| `/hyperskills:research` | Need deeper investigation first |
| `/hyperskills:orchestrate` | Ready to dispatch agents |
| Direct implementation | Simple enough to just build |
| Write a spec | Needs formal documentation |
### Output
> **Decision:** [what we're doing]
> **Approach:** [which option, brief description]
> **Why:** [1-2 sentences on the reasoning]
> **Next:** [the immediate next action]
---
## Quick Mode
For small decisions that don't need the full diamond: search Sibyl, present two options with tradeoffs, decide, record. Skip problem exploration entirely when the problem is already well-understood and the user just needs help choosing between known options. Most "brainstorms" are actually this.
---
## Multi-Agent Brainstorming
For complex architectural decisions, deploy a **Council pattern:**Agent 1 (Advocate): Makes the strongest case FOR approach A
Agent 2 (Advocate): Makes the strongest case FOR approach B
Agent 3 (Critic): Finds flaws in BOTH approaches
Synthesize their outputs, then present the unified analysis to the user.
**When to use:** Architecture decisions affecting 3+ systems, technology selection, major refactors. Don't use for simple feature design.
---
## Anti-Patterns
| Anti-Pattern | Fix |
| ----------------------------------------- | ------------------------------------------------ |
| Jumping to solutions before defining pain | Spend one pass on the problem frame first |
| Asking a stack of questions at once | Ask one load-bearing question, then adapt |
| Presenting seven "maybe" options | Offer 2-3 real choices with tradeoffs |
| Ignoring prior decisions in Sibyl | Search memory first and surface relevant context |
| Brainstorming when the user said build it | Switch to implementation and keep momentum |
---
## What This Skill is NOT
- **Not a gate.** You don't need permission to skip phases. If the user says "just build it," build it.
- **Not a waterfall.** Phases can revisit. New information in Phase 4 can send you back to Phase 2.
- **Not a document generator.** The output is a decision, not a design doc (unless the user wants one).
- **Not required for everything.** Bug fixes, typo corrections, and clear-spec features don't need brainstorming.
## YAGNI Check
Before concluding, ask: **"Is there anything in this plan we don't actually need yet?"** Strip it. Build the minimum that validates the approach.