hm-l2-brainstorm

Files (8)

• SKILL.md
• evals.json · evals/
• rich-gate-scorecard.md · metrics/
• assumption-detection.md · references/
• handoff-template.md · references/
• question-patterns.md · references/
• .gitkeep · scripts/
• task_plan.md

SKILL.md (first lines)

# Brainstorming: Intent → Requirements

Bridge vague user intent to a formal requirements brief through structured questioning, assumption detection, and scope surfacing. This skill owns the ideation-to-requirements phase. It does NOT design solutions — only clarifies WHAT needs to be built.

This package synthesizes three inspected third-party patterns:

| Source | Adopt / Adapt decision | Local transformation |
|--------|------------------------|----------------------|
| `obra/superpowers@brainstorming` | Adopt sequential questioning, hard-gate-before-code, one-question-at-a-time, approach comparisons. Adapt away from superpowers-specific paths. | Use Gate 1 (no implementation before requirements brief approved), one-question-at-a-time, approach comparison in Phase 2. |
| `ratacat/claude-skills@brainstorming` | Adopt YAGNI principles, question techniques, anti-patterns table, handoff options. Adapt generic design doc → hm-specific requirements brief. | Use YAGNI filter in Phase 2, question techniques in Phase 1, anti-patterns throughout. |
| `Jamie-BitFlight/brainstorming-skill` | Adopt assumption challenge technique, constraint variation. Defer creative ideation patterns (perspective multiplication, inversion, SCAMPER). | Use assumption challenge in Phase 1.3, constraint variation in Phase 2.1. |

## HARD GATE — No Code Before Requirements Brief

```
DO NOT write code, scaffold projects, or invoke implementation skills
until the requirements brief is produced AND approved by the user.
This applies to EVERY project regardless of perceived simplicity.
```

## Entry Gate

Proceed when any of these are true:
- User said "brainstorm", "ideation", "figure out what to build", "explore ideas"
- User intent is vague or underspecified (missing constraints, success criteria, scope)
- User describes a problem without specifying a solution direction
- A coordinator skill (`hm-user-intent-interactive-loop`, `hm-coordinating-loop`) routes to this skill

Do NOT proceed when:
- A PRD, spec, or formal requirements document already exists → route to `hm-spec-driven-authoring`
- The task is a straightforward bug fix with clear expected behavior → execute directly
- The user says "just do it", "I know exactly what I want" with explicit details

## Checklist

Create a task for each item and complete them in order. Do not skip phases.

- [ ] Phase 1: Understand Intent — structured questioning, assumption detection, scope surfacing
- [ ] Phase 2: Explore Requirements — approach options, constraint mapping, priority setting
- [ ] Phase 3: Produce Requirements Brief — structured output for handoff
- [ ] Phase 4: Handoff — route to next skill (hm-spec-driven-authoring, hm-deep-research, or hm-detective)

## Phase 1: Understand Intent

### 1.1 Gather Context

Before asking the user any questions:
1. Check project files: `README.md`, instruction files (`AGENTS.md` or equivalent), `package.json`, recent commits
2. Identify the project domain, stack, and existing patterns
3. Check for existing specs, PRDs, or design docs that relate to the request
4. If the request mentions a specific file or module, read it

### 1.2 Assess Scope

Flag scope issues immediately — do NOT burn questions on something that needs decomposition first.

**Multi-system signal:** If the request describes multiple independent subsystems (e.g., "build a platform with auth, payments, and real-time chat"), stop and say:

> "This request spans multiple independent systems: [list them]. Each needs its own requirements brief. Which should we start with?"

**Appropriately scoped:** A single feature, component, module, or workflow. Continue to Phase 1.3.

### 1.3 Ask Clarifying Questions

**One question at a time.** Prefer multiple choice when natural options exist. Break complex topics into multiple questions.

Use question patterns from `references/question-patterns.md`. Default priority order:

| Priority | Category | Example |
|----------|----------|---------|
| 1 | Purpose | "What problem does this solve? (a) automate existing workflow, (b) add new capability, (c) replace legacy system" |
| 2 | Users | "Who uses this? (a) developers, (b) end-users, (c) admins — or multiple?" |
| 3 | Constraints | "Any hard constraints? Technology, timeline, compliance, dependencies?" |
| 4 | Success | "How will you know this is working? What does success look like?" |
| 5 | Scope boundaries | "What should this explicitly NOT do?" |

**Stop conditions (any of these):**
- User says "proceed", "let's move on", "that's enough questions"
- 5 questions asked (stop and surface what you have)
- All 5 priority categories covered with clear answers
- The intent is clear enough to state: "We need to build [X] so that [Y] can [Z]"

### 1.4 Detect Unstated Assumptions

After gathering answers, run assumption detection using `references/assumption-detection.md`:

1. List every assumption you made about the user's request
2. Validate explicit assumptions with the user: "I'm assuming [X]. Is that correct?"
3. Surface implicit assumptions the user may not have considered: "This implies [Y] will need to happen. Is that in scope?"

Record all validated assumptions in the requirements brief.

### 1.5 Pause for Confirmation

After questions are exhausted (max 5), restate your understanding:

```markdown
## Intent Summary

**Problem:** [1-2 sentences]
**Target users:** [who]
**Success looks like:** [measurable outcome]
**In scope:** [what's included]
**Out of scope:** [what's explicitly excluded]
**Key constraints:** [hard boundaries]
**Validated assumptions:** [confirmed assumptions]

Does this match what you had in mind? Adjustments before we explore requirements?
```

Wait for user confirmation before proceeding to Phase 2.

## Phase 2: Explore Requirements

### 2.1 Propose 2-3 Approach Directions

Not implementations — requirement shapes. For each approach, describe:

```markdown

From shynlee04/hivemind-plugin, MIT.

More from shynlee04/hivemind-plugin