/cm-brainstorm-idea

name: cm-brainstorm-idea
description: "Strategic analysis gate for existing products — multi-dimensional evaluation (tech, product, design, business) using Design Thinking + 9 Windows (TRIZ) + Double Diamond. Outputs 2-3 qualified options with recommendations. Use BEFORE cm-planning for complex initiatives and enhancements on existing codebases."
token_budget: 1500
compressed: true
deprecated: false

Brainstorm Idea — Strategic Analysis Gate

TL;DR

• **Use before** cm-planning for complex/ambiguous initiatives
• **Frameworks**: Design Thinking + 9 Windows (TRIZ) + Double Diamond
• **Output**: 2-3 qualified options + recommendation
• **Writes**: handoff/intent.json

> **Understand deeply. Evaluate multi-dimensionally. Propose qualified options. Then — and only then — plan.** > This skill is the BRIDGE between an existing product and its next evolution.

When to Use

**ALWAYS when:**

• User requests complex changes to an existing product
• Initiatives or enhancements that touch multiple system areas
• User jumps straight into hard/complex tasks without analysis
• Post `cm-project-bootstrap` — product exists, needs improvement
• Feature requests that could be solved in fundamentally different ways
• "What should we do next?" / "What to improve?" / "Enhancement" / "Initiative"

**Skip when:**

• Simple bug fixes (use `cm-debugging`)
• New project from scratch (use `cm-project-bootstrap`)
• Task is already clearly defined and scoped (go to `cm-planning`)
• Quick one-off changes (< 30 min work)

Gate Function

User requests complex task
  → Is the problem clearly understood and qualified?
    → NO → Run cm-brainstorm-idea FIRST
    → YES → Go to cm-planning directly

When downstream skills detect an unqualified complex request, they should REDIRECT here:

cm-planning detects ambiguity → "Problem not clear. Run cm-brainstorm-idea first."
cm-execution gets vague plan  → "Plan lacks context. Go back to cm-brainstorm-idea."

---

The Process

Phase 1: DISCOVER     (Diamond 1 — Diverge)   → Scan wide, understand current state
Phase 2: DEFINE       (Diamond 1 — Converge)   → Qualify the REAL problem
Phase 3: DEVELOP      (Diamond 2 — Diverge)    → Generate 2-3 solution options
Phase 4: EVALUATE     (Diamond 2 — Converge)   → Score, compare, recommend
Phase 4.5: UI PREVIEW (Visual Validation)       → See it before you build it
Phase 5: HANDOFF      (Bridge to cm-planning)   → Package for downstream skills

Phase 1: DISCOVER — Scan & Empathize

> **Goal:** Understand the current state of the product from all angles.

1a. Codebase Scan

Read and map the existing system:

✅ DO:
- Read .cm/skeleton.md for instant overview. If missing, run `cm index skeleton`.
- Read .cm/architecture.mmd for an instant architectural diagram.
- IF codegraph is available (`codegraph status`):
  → Use `codegraph_files` to summarize project.
  → Use graph to identify most connected modules and dead code.
- Read AGENTS.md and key config files.
- Check test coverage and existing quality.

📋 OUTPUT: Codebase Summary
- Tech stack & Architecture: [...]
- Key dependencies & Test coverage: [...]
- Code health & Codebase insights (from skeleton/codegraph): [...]
- Present architecture diagram to user (if .cm/architecture.mmd exists).
- Corpus size: [total source files] src / [total doc files] docs

🔍 SIZE CHECK (auto — triggers cm-deep-search/cm-codeintell):
  IF docs/ > 50 files OR source > 200 files:
    → Suggest: "This project is quite large. Run `cm index skeleton` and see cm-deep-search to setup semantic search."
    → Non-blocking: continue Phase 1 regardless of user response

1b. User Context Interview

Ask targeted questions to understand intent:

📋 DISCOVERY QUESTIONS:
1. Who does the current product serve? (Target users?)
2. What is the biggest pain point right now? (Biggest pain point?)
3. What is the next business goal? (Next business goal?)
4. Are there any tech/budget/timeline constraints? (Constraints?)
5. What solutions have already been tried? (What's been tried?)

1c. Multi-Dimensional Current State

| Dimension | What to Assess | Sources | |-----------|---------------|---------| | **Tech** | Code quality, scalability, tech debt, performance | Codebase scan, test results | | **Product** | Feature completeness, user satisfaction, funnel gaps | User interview, analytics | | **Design** | UX quality, accessibility, mobile readiness, design system | UI review, `cm-ux-master` | | **Business** | Revenue impact, market position, competitive landscape | User interview, research |

---

Phase 2: DEFINE — Qualify the Problem

> **Goal:** Use 9 Windows to see the problem from all time × system perspectives, then converge on the REAL problem.

9 Windows Analysis (TRIZ)

Map the situation across time and system levels:

┌─────────────────┬──────────────────┬──────────────────┬──────────────────┐
│                 │     PAST         │    PRESENT       │    FUTURE        │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ SUPER-SYSTEM    │ Market/industry  │ Current market   │ Where market     │
│ (ecosystem)     │ was like this... │ looks like...    │ is heading...    │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ SYSTEM          │ Product used to  │ Product now      │ Product should   │
│ (the product)   │ be like this...  │ does this...     │ become this...   │
├─────────────────┼──────────────────┼──────────────────┼──────────────────┤
│ SUB-SYSTEM      │ Components were  │ Components now   │ Components need  │
│ (components)    │ built this way...│ work this way... │ to evolve to...  │
└─────────────────┴──────────────────┴──────────────────┴──────────────────┘

**Fill all 9 windows** based on Phase 1 findings. This reveals:

• Evolution patterns (Past → Present trends)
• System-level tensions (Super-system demands vs Sub-system capabilities)
• Future opportunities (w