nw-brainstorming

Structured divergent thinking techniques — HMW framing, SCAMPER, Crazy 8s mechanics, and option diversity guarantees. Enforces strict separation of generation and evaluation phases.

322 stars

Best use case

nw-brainstorming is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Structured divergent thinking techniques — HMW framing, SCAMPER, Crazy 8s mechanics, and option diversity guarantees. Enforces strict separation of generation and evaluation phases.

Teams using nw-brainstorming should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/nw-brainstorming/SKILL.md --create-dirs "https://raw.githubusercontent.com/nWave-ai/nWave/main/nWave/skills/nw-brainstorming/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/nw-brainstorming/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How nw-brainstorming Compares

Feature / Agentnw-brainstormingStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Structured divergent thinking techniques — HMW framing, SCAMPER, Crazy 8s mechanics, and option diversity guarantees. Enforces strict separation of generation and evaluation phases.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Structured Brainstorming

## The Separation Principle — Foundational Rule

Generation and evaluation CANNOT happen simultaneously. Osborn (1953): "You cannot get hot and cold water from the same faucet at the same time — you only get tepid water."

**Consequence for the agent**: All options must be generated before any option is scored. Never filter or rank during generation. Self-censorship during generation degrades both the quality of ideas and the quality of evaluation.

---

## Phase 1: HMW Framing — Set Up the Ideation Space

Before generating any options, reframe the problem as a "How Might We" question.

**Rules for valid HMW questions**:
- No embedded solutions: "How might we make onboarding faster?" ✓ vs "How might we add tooltips?" ✗
- Outcome-oriented, not feature-oriented
- Broad enough for genuinely different approaches
- Positive framing (not "How might we avoid X?")

**Example transformation**:
- Feature request: "Add a dashboard to show workflow status"
- Bad HMW: "How might we build a better dashboard?"
- Good HMW: "How might we give teams confidence that their workflow is progressing correctly?"

The good HMW opens the solution space: the answer isn't necessarily a dashboard.

---

## Phase 2: SCAMPER — 7 Structurally Different Lenses

Apply each SCAMPER lens to the validated job to generate one option per letter. This guarantees structural diversity — each letter produces a categorically different type of option.

| Letter | Lens | Question | What it produces |
|--------|------|----------|-----------------|
| **S** | Substitute | What if the core mechanism were replaced entirely? | Alternative technology/approach |
| **C** | Combine | What if this job were merged with an adjacent job? | Integrated solution |
| **A** | Adapt | What works well in a different domain? Could we borrow it? | Cross-domain transfer |
| **M** | Modify/Magnify | What if the most important dimension were amplified? | Focused excellence |
| **P** | Put to other use | Who else has this job? Could the solution serve them too? | Market extension |
| **E** | Eliminate | What if we removed the most complex part? | Radical simplification |
| **R** | Reverse | What if the workflow ran backwards? User and system switched roles? | Inversion |

**Required output**: At minimum, one option per SCAMPER letter. Name each option clearly. Do not evaluate during generation.

---

## Phase 3: Crazy 8s Supplement — Volume and Self-Censorship Removal

After SCAMPER, generate 2-4 additional options by imagining you have only 1 minute per idea. The time pressure mechanic prevents evaluation creep.

**Constraint**: Each additional option must differ structurally from all SCAMPER options. Not a variation — a different type of approach.

---

## Phase 4: Option Curation — Converge to 6

Before handing off to taste evaluation:

1. List all generated options (7+ from SCAMPER + supplements)
2. Remove exact duplicates only — not similar ones, exact
3. Group options that are genuine variations of the same approach → keep the strongest representative
4. Target: **6 options** for evaluation (evidence-backed sweet spot: enough diversity, evaluable without overload)

**Diversity test** — each of the 6 options should answer yes to:
- Different mechanism? (not just variation in degree)
- Different assumption about user behavior?
- Different cost/effort profile?

If two options share all three, they are variations — merge them.

---

## Option Format

Each option in `options-raw.md` must follow:

```
### Option N: [Name]

**Core idea**: One sentence — what would a user actually experience?
**Key mechanism**: What makes this work?
**Key assumption**: What must be true for this to succeed?
**SCAMPER origin**: Which lens generated this? (or "Crazy 8s supplement")
**Closest competitor**: What existing product does this most?
```

---

## Anti-Patterns to Avoid

| Anti-pattern | Why it fails | Correction |
|-------------|-------------|-----------|
| Generating one good idea and elaborating it | Confirmation bias — narrows too early | Apply all SCAMPER letters before stopping |
| "Improved version of the existing approach" | Not divergent — variation, not option | Apply E (Eliminate) or R (Reverse) |
| Filtering during generation ("that won't work") | Destroys divergent thinking | Generate everything, filter in taste phase |
| Options that share the same core mechanism | False diversity | Apply diversity test before curating |
| Skipping HMW framing | Solution space collapses prematurely | HMW must precede any generation |

---

## DIVERGE Output for Brainstorming Phase

Produce `docs/feature/{feature-id}/diverge/options-raw.md` with:

1. **HMW question** — the validated framing
2. **SCAMPER options** — one per letter, named and described
3. **Crazy 8s supplements** — 2-4 additional structurally distinct options
4. **Curated 6** — with diversity test results
5. **Eliminated options** — brief note on why merged/removed

**Gate**: 6 curated options, each passing the 3-point diversity test, before taste evaluation begins.

Related Skills

nw-ux-web-patterns

322
from nWave-ai/nWave

Web UI design patterns for product owners. Load when designing web application interfaces, writing web-specific acceptance criteria, or evaluating responsive designs.

nw-ux-tui-patterns

322
from nWave-ai/nWave

Terminal UI and CLI design patterns for product owners. Load when designing command-line tools, interactive terminal applications, or writing CLI-specific acceptance criteria.

nw-ux-principles

322
from nWave-ai/nWave

Core UX principles for product owners. Load when evaluating interface designs, writing acceptance criteria with UX requirements, or reviewing wireframes and mockups.

nw-ux-emotional-design

322
from nWave-ai/nWave

Emotional design and delight patterns for product owners. Load when designing onboarding flows, empty states, first-run experiences, or evaluating the emotional quality of an interface.

nw-ux-desktop-patterns

322
from nWave-ai/nWave

Desktop application UI patterns for product owners. Load when designing native or cross-platform desktop applications, writing desktop-specific acceptance criteria, or evaluating panel layouts and keyboard workflows.

nw-user-story-mapping

322
from nWave-ai/nWave

User story mapping for backlog management and outcome-based prioritization. Load during Phase 2.5 (User Story Mapping) to produce story-map.md and prioritization.md.

nw-tr-review-criteria

322
from nWave-ai/nWave

Review dimensions and scoring for root cause analysis quality assessment

nw-tlaplus-verification

322
from nWave-ai/nWave

TLA+ formal verification for design correctness and PBT pipeline integration

nw-test-refactoring-catalog

322
from nWave-ai/nWave

Detailed refactoring mechanics with step-by-step procedures, and test code smell catalog with detection patterns and before/after examples

nw-test-organization-conventions

322
from nWave-ai/nWave

Test directory structure patterns by architecture style, language conventions, naming rules, and fixture placement. Decision tree for selecting test organization strategy.

nw-test-design-mandates

322
from nWave-ai/nWave

Four design mandates for acceptance tests - hexagonal boundary enforcement, business language abstraction, user journey completeness, walking skeleton strategy, and pure function extraction

nw-tdd-review-enforcement

322
from nWave-ai/nWave

Test design mandate enforcement, test budget validation, 5-phase TDD validation, and external validity checks for the software crafter reviewer