/openlore-brainstorm

name: openlore-brainstorm
description: Transform a feature idea into an annotated story using a Domain Sketch or Constrained Option Tree. Use when asked to brainstorm, explore, or shape a feature before implementation.

openlore: Brainstorm

When to use this skill

Trigger this skill when the user wants to **explore or design a new feature** before writing any code, with phrasings like:

• "I want to add feature X"
• "how should I approach this?"
• "let's brainstorm this story"
• explicit command `/openlore-brainstorm`

---

Step 1 — Detect mode

Capture `$PROJECT_ROOT`, `$FEATURE_DESCRIPTION`, and `$FEATURE_SLUG` (kebab-case, ≤ 5 words, e.g. `payment-retry-flow`).

Then probe the structural index by calling the openlore MCP tool `orient` with:

{
  "directory": "$PROJECT_ROOT",
  "task": "$FEATURE_DESCRIPTION",
  "limit": 7
}

Set `$MODE` based on the result:

| Result | `$MODE` | Meaning | |---|---|---| | Returns functions with score > 0 | `brownfield` | Existing indexed codebase | | Returns `"error": "no cache"` or 0 functions | `greenfield` | No structural index yet |

Inform the user:

• Brownfield: "I found existing code related to this feature. Using structural analysis to guide design."
• Greenfield: "No structural index found. Using Domain Sketch — structural analysis will be available after `openlore analyze` is run on the first implementation."

**Load project antipatterns (both modes):**

If `.claude/antipatterns.md` exists, read it and store as `$ANTIPATTERNS`. These will be used as a failure mode source in Step 5. If absent, `$ANTIPATTERNS = none`.

---

Steps 2–4 — Structural analysis (brownfield only)

*Skip to Step 5 if `$MODE = greenfield`.*

Step 2 — Architecture overview

Call the openlore MCP tool `get_architecture_overview` with `{"directory": "$PROJECT_ROOT"}`.

Note hub functions and cross-domain dependencies in `$DOMAINS_AFFECTED`.

Step 3 — Generate change proposal

Call the openlore MCP tool `generate_change_proposal` with:

{
  "directory": "$PROJECT_ROOT",
  "description": "$FEATURE_DESCRIPTION",
  "slug": "$FEATURE_SLUG"
}

This chains `orient` + `search_specs` + `analyze_impact` and writes `openspec/changes/$FEATURE_SLUG/proposal.md`.

Extract:

• **`$MAX_RISK_SCORE`** — overall risk level
• **`$REQUIREMENTS_TOUCHED`** — existing requirements this feature overlaps
• **`$BLOCKING_REFACTORS`** — functions with risk ≥ 70

Step 4 — Risk gate

| Score | Action | |---|---| | 🟢 < 40 | Proceed to Step 5 | | 🟡 40–69 | Proceed, flag impacted callers to protect during design | | 🔴 ≥ 70 | Stop — propose a blocking refactor story before continuing |

If blocked: > "This feature touches `$BLOCKING_FUNCTION` (risk score: $SCORE). > A refactor story must be completed first. I can create it now if you'd like."

Do not continue until the user accepts the refactor story or explicitly overrides.

---

Step 5 — Brainstorming

If `$MODE = brownfield` — Constrained Option Tree

**5a — Establish the constraint space**

Derive from Steps 2–4 and present before generating options:

Hard constraints (non-negotiable):
  - Functions with riskScore ≥ 70: $BLOCKED_FUNCTIONS
  - Requirements that must be preserved: $REQUIREMENTS_TOUCHED
  - Domain boundaries that must not be crossed: $DOMAIN_BOUNDARIES

Soft constraints (preferred):
  - Existing insertion points: $INSERTION_POINTS
  - Patterns already used in $DOMAINS_AFFECTED

Ask: "Are there additional constraints before we explore approaches?"

**5b — Generate 2–3 options**

Each option must respect hard constraints. Name them clearly (e.g. Option A — Extend existing, Option B — New service, Option C — Facade).

If `$ANTIPATTERNS ≠ none`, cross-check each option against the list. Flag any option that would reproduce a known failure pattern with ⚠ and the relevant AP-NNN.

| | Option A | Option B | Option C | |---|---|---|---| | Insertion point | | | | | Domains touched | | | | | Risk score impact | | | | | Requirements affected | | | | | Estimated scope (files) | | | | | Trade-off | | | |

**5c — Recommend**

State one recommendation with a single structural reason:

> "Recommend Option B — inserts at `$SAFE_FUNCTION` (risk 18), avoids `$HUB` > (fan-in 14) entirely. Option A is valid but adds unnecessary blast radius."

**5d — Confirm**

Do not proceed to Step 5e until the user chooses. If they want a hybrid, produce a revised option table.

**5e — Adversarial challenge**

Before writing the story, switch roles: challenge the chosen option as a skeptic.

State exactly 2 failure modes grounded in the structural data and, if `$ANTIPATTERNS ≠ none`, any applicable antipatterns from `.claude/antipatterns.md`:

> "Devil's advocate on Option B: > 1. `$CALLER_A` calls `$INSERTION_POINT` with `$EDGE_CASE` — this path is not covered > by the proposed approach and could silently break. > 2. The proposal scores risk at $SCORE but `$HUB` (fan-in $N) is one hop away — > a regression there would not be caught until `check_spec_drift`."

Then ask the user: "Do these failure modes change your choice, or should we add mitigations to the story constraints?"

Only proceed to Step 6 once the user has acknowledged the failure modes. Mitigations go into `## Technical Constraints` in the story.

> Note: this IS a gate (waits for user input) because brainstorm is a design phase > where changing course is cheap. In contrast, `openlore-implement-story` Step 4b > is a mandatory self-check that does NOT gate — because by implementation time > the design decision is already made.

Ask: "What is explicitly out of scope for this story?" List the answers as `$WONT_DO`.

---

If `$MODE = greenfield` — Domain Sketch

No existing structure to constrain — the method builds the structure from scratch.

**5a — Entities**

Ask the user: "What are the core data objects this feature creates or transforms?"

List them as nouns with a one-line definition each:

$ENTITY_1 — definition
$ENTITY_2 — de