Brainstorm: Business Goal → Milestones → Outcomes → Work Units

Help user turn a business goal into well-defined Milestones, Outcomes, and Work Units.

Linear Hierarchy:

code

Project (Business Goal)
└── Milestone (Epic - major deliverable, optional target date)
    └── Issue (Outcome - user-facing value with success metric)
        └── Sub-issue (Work Unit - implementation with Gherkin specs)

Level	Linear Object	What It Represents	Example
Project	Project	Business Goal	"Land Intelligence App V1"
Milestone	Milestone	Epic / Major Deliverable	"User Authentication"
Outcome	Issue	User-facing value	"User can register"
Work Unit	Sub-issue	Implementation task	"WU: Registration API"

Usage

code

/brainstorm [initiative-name or goal description]
/brainstorm --status "Project Name"

Important: Using Linear MCP

Use Linear MCP tools as direct function calls, NOT bash commands.

Status Mode: `--status`

When invoked with --status "Project Name", skip the brainstorm workflow and show current project state.

How to Fetch Status

•
Find the project:
code
```
mcp__linear-server__list_projects
```
Match by name to get project ID.

•

Fetch all issues for the project:

code

mcp__linear-server__list_issues:
  project: [project ID]
  includeArchived: false

•

For each issue, fetch details including relations:

code

mcp__linear-server__get_issue:
  id: [issue ID]
  includeRelations: true

Status Report Format

Present the status grouped by Milestone:

code

## Project Status: [Project Name]

**Overall Progress:** X of Y Work Units complete (Z%)

---

### Milestone: [Milestone 1 Name] 🎯
**Target:** [date or "No target"]
**Progress:** A of B Work Units (C%)

| Status | Issue | Title | Blocked By |
|--------|-------|-------|------------|
| ✅ | BHU-101 | [Outcome 1] | — |
| ✅ | └─ BHU-102 | WU: [title] | — |
| 🔄 | BHU-103 | [Outcome 2] | — |
| ⬜ | └─ BHU-104 | WU: [title] | BHU-102 |

---

### Milestone: [Milestone 2 Name] 🎯
**Target:** [date]
**Progress:** 0 of D Work Units (0%)
**Blocked by:** Milestone 1

| Status | Issue | Title | Blocked By |
|--------|-------|-------|------------|
| 🔴 | BHU-201 | [Outcome 3] | BHU-103 |

---

### Summary

| Milestone | Progress | Target | Status |
|-----------|----------|--------|--------|
| [Milestone 1] | 2/4 (50%) | Feb 15 | 🔄 In Progress |
| [Milestone 2] | 0/3 (0%) | Mar 1 | 🔴 Blocked |

### Critical Path
Milestone 1: BHU-102 → BHU-104 (completes milestone)
Then: Milestone 2: BHU-201 → BHU-203

**Next action:** Run `/work BHU-104` to continue Milestone 1.

Status Icons

Icon	Meaning
✅	Completed
🔄	In Progress
🟢	Ready to Start (unblocked)
🔴	Blocked
⬜	Not Started

Workflow

Phase 0: Identify Project

•Fetch existing projects via mcp__linear-server__list_projects

•Ask user:

code

Which project should this work go into?
1. [Project A] (existing)
2. [Project B] (existing)
...
N. Create new project

Or specify: /brainstorm --project "Project Name" ...

•If new project, get name and create via mcp__linear-server__create_project
•Store project ID for later phases

Phase 1: Understand the Goal

•If user provided goal description, clarify it
•
Ask clarifying questions ONE AT A TIME:
- •What problem are we solving?
- •Who benefits? (user segment)
- •What does success look like?
- •Any constraints? (time, tech, scope)
•Summarize understanding, confirm with user

Phase 2: Propose Milestones

Milestones are major deliverables — significant chunks of functionality that can be shipped or demonstrated.

•
Based on the goal, identify natural phases/epics:
- •What are the major capability areas?
- •What could be shipped incrementally?
- •Are there natural dependencies between areas?

•

Propose 2-5 Milestones:

code

## Proposed Milestones

1. **[Milestone name]** (e.g., "User Authentication")
   - Delivers: [what user can do when this is complete]
   - Target: [suggested timeframe or "TBD"]
   - Dependencies: [other milestones that must come first, or "None"]

2. **[Milestone name]** (e.g., "Land Parcel CRUD")
   - Delivers: [what user can do]
   - Target: [timeframe]
   - Dependencies: [Milestone 1]

3. **[Milestone name]**
   ...

•
Ask user to approve, modify, reorder, or remove
•
Confirm milestone sequence and any target dates

Phase 3: Propose Outcomes (per Milestone)

For each approved Milestone:

Before proposing, run a Necessity Check for each potential Outcome.

Every line of code is a liability. The best solution is often no new code at all.

•
For each potential Outcome, investigate:
- •Existing solution? Search codebase for similar functionality
- •Config change? Could this be achieved by changing settings/env vars?
- •Library/tool? Is there an existing package that solves this?
- •80/20 alternative? Could we get 80% of the value with 20% of the effort?

•

Propose Outcomes for this Milestone:

code

## Milestone: [name]

### Proposed Outcomes

1. **[Outcome name]** (e.g., "User can register")
   - Want: [1-2 sentences of user-facing value]
   - Success metric: [measurable]
   - Complexity: Low/Medium/High
   - Necessity check:
     - Existing solution: [None found / Found X but doesn't cover Y]
     - Config alternative: [Not applicable / Considered but Z]
     - Library option: [None suitable / X exists but Y reason not to use]
     - 80/20: [This IS the minimal approach / Could do X instead for less]

2. **[Outcome name]** (e.g., "User can log in")
   ...

•
Ask user to approve, modify, or remove each Outcome
•
Confirm final set before proceeding to Work Units
•
Repeat for each Milestone

Phase 4: Break Down into Work Units

For each approved Outcome:

•
Explore codebase to understand technical scope

•

Propose Work Units (one per repo — if feature spans repos, create separate linked WUs):

code

## Outcome: [name]

Work Units:
1. WU: [title]
   - Repo: [exact repo name, e.g., bhume-platform, bhume-mobile]
   - Proof type: [tdd/rn-component/dbt-test/infra-runbook]
   - Budget estimate: [small/medium/large]
   - Key scenarios (draft):
     - [scenario 1]
     - [scenario 2]

2. WU: [title] (if multi-repo)
   - Repo: [different repo]
   - Blocked by: WU-1 (if dependent)
   ...

Multi-repo features: Create separate Work Units for each repo with explicit dependencies. Example: API change (backend repo) → Mobile integration (mobile repo, blocked by API WU)

•
Get user approval on breakdown

Phase 4.5: Map Dependencies

After all Work Units are approved, identify execution order:

•
Analyze dependencies at multiple levels:
- •Milestone-level: Which milestones depend on others?
- •Outcome-level: Which outcomes within a milestone depend on others?
- •Work Unit-level: Which WUs produce artifacts others need?

•

Present dependency graph:

code

## Execution Order

### Milestone 1: [name]

Phase 1 (No blockers - can start now):
- BHU-XXX: [title]
- BHU-YYY: [title]

Phase 2 (After Phase 1):
- BHU-ZZZ: [title] ← blocked by BHU-XXX

Critical Path: BHU-XXX → BHU-ZZZ → BHU-AAA

### Milestone 2: [name] (after Milestone 1)

Phase 1:
- BHU-BBB: [title] ← blocked by BHU-AAA (from Milestone 1)

•

Present summary table:

code

| Milestone | Order | Issue | Title | Blocked By |
|-----------|-------|-------|-------|------------|
| Auth | 1 | BHU-XXX | [title] | — |
| Auth | 2 | BHU-YYY | [title] | BHU-XXX |
| CRUD | 3 | BHU-ZZZ | [title] | BHU-YYY |

•
Get user approval on dependencies before creating in Linear

Phase 5: Create in Linear

Hierarchy: Project → Milestone → Issue (Outcome) → Sub-issue (Work Unit)

•
Get team ID via mcp__linear-server__list_teams

•

Check if Project exists for this Business Goal, or create one:

code

mcp__linear-server__create_project:
  name: [Business Goal / Initiative name]
  team: [team ID]
  description: [1-2 sentence goal]

•
For each Milestone, note the name (milestones are created implicitly when first issue references them, or may already exist)

•

For each Outcome, create parent Issue associated with its Milestone:

code

mcp__linear-server__create_issue:
  title: [Outcome name]
  team: [team ID]
  project: [project ID]
  milestone: [Milestone name]
  description: |
    ## Want
    [from approved outcome]

    ## Success Metric
    - Primary: [metric]
    - Secondary: [metric] (optional)

    ## Status
    - [ ] Work Units defined
    - [ ] Work Units complete
    - [ ] Success metric verified

•

For each Work Unit, create Sub-issue under Outcome (inherits milestone from parent):

code

mcp__linear-server__create_issue:
  title: WU: [title]
  team: [team ID]
  project: [project ID]
  parentId: [Outcome issue ID from step 4]
  milestone: [Milestone name]
  labels: [proof type, budget]
  description: |
    ## Want
    [1-2 sentences]

    ## Repo
    [exact repo name, e.g., bhume-platform]

    ## Done When
    ```gherkin
    Scenario: [from draft scenarios]
      Given ...
      When ...
      Then ...
    ```

    ## Approach
    TBD - agent proposes during /work

    ## Decisions
    <!-- Added during implementation -->

•
Add blocking relationships from Phase 4.5:
code
```
mcp__linear-server__update_issue:
  id: [Work Unit issue ID]
  blockedBy: ["BHU-XXX", "BHU-YYY"]  # Issues that must complete first
```
Note: This includes cross-milestone dependencies (e.g., Milestone 2's first WU blocked by Milestone 1's last WU).

Phase 6: Summary

Report what was created:

code

## Brainstorm Complete

**Project:** [Business Goal name] ([Linear URL])

---

### Milestone 1: [name] 🎯
**Target:** [date]
**Outcomes:** N

- [Outcome 1] ([Linear URL])
  - WU: [title] ([Linear URL])
  - WU: [title] ([Linear URL])
- [Outcome 2] ([Linear URL])
  - WU: [title] ([Linear URL])

### Milestone 2: [name] 🎯
**Target:** [date]
**Blocked by:** Milestone 1
**Outcomes:** M

- [Outcome 3] ([Linear URL])
  - WU: [title] ([Linear URL])

---

## Execution Summary

| Milestone | Outcomes | Work Units | Target |
|-----------|----------|------------|--------|
| [Milestone 1] | 2 | 4 | Feb 15 |
| [Milestone 2] | 1 | 2 | Mar 1 |
| **Total** | **3** | **6** | |

## Start Here (No Blockers)

| Issue | Title | Milestone |
|-------|-------|-----------|
| BHU-XXX | [title] | [Milestone 1] |
| BHU-YYY | [title] | [Milestone 1] |

## Critical Path

Milestone 1: BHU-XXX → BHU-ZZZ → BHU-AAA (milestone complete) ↓ Milestone 2: BHU-BBB → BHU-CCC (project complete)

code


**Next:** Run `/work BHU-XXX` to begin Milestone 1.

Principles

•One question at a time — Don't overwhelm
•User approves each phase — Don't create without approval
•Milestones are shippable — Major deliverables, not arbitrary groupings
•Outcomes are user-facing — Not technical tasks
•Work Units are implementation — Technical, with Gherkin
•YAGNI — Remove anything not essential
•Dependencies flow down — Milestones → Outcomes → Work Units

Quick Reference: What Goes Where

Question	Answer
"When will Auth be done?"	Check Milestone target date
"What can the user do?"	Check Outcomes
"What needs to be built?"	Check Work Units
"What's blocking progress?"	Check dependencies in Status
"What should I work on next?"	Run `/brainstorm --status`

Brainstorm: Business Goal → Milestones → Outcomes → Work Units

Usage

Important: Using Linear MCP

Status Mode: --status

How to Fetch Status

Status Report Format

Status Icons

Workflow

Phase 0: Identify Project

Phase 1: Understand the Goal

Phase 2: Propose Milestones

Phase 3: Propose Outcomes (per Milestone)

Phase 4: Break Down into Work Units

Phase 4.5: Map Dependencies

Phase 5: Create in Linear

Phase 6: Summary

Principles

Quick Reference: What Goes Where

Status Mode: `--status`