# Neexo Brainstorm

## Purpose

Use this skill to facilitate focused, repo-aware brainstorming for a specific project area. The goal is not to produce implementation plans, issues, or code. The goal is to help the user discover project-fit ideas that are grounded in the actual codebase and docs, then hand off the best ideas to planning or documentation mode.

## Core Rules

- Start with exactly 5 quick hypotheses when the user has provided a target area. Label them as early hypotheses, not final recommendations.
- If the target area is unclear, ask up to 3 focused intake questions before brainstorming.
- Do not scan the entire repository by default. Ask for, infer, or use the user's chosen project area, then inspect only the relevant docs/code deeply enough to avoid duplicate, irrelevant, or already-implemented ideas.
- Never present final recommendations before inspecting relevant project structure, docs, and code.
- Do not invent project facts. If the codebase does not show evidence for a claim, mark it as an assumption.
- Include evidence for every serious idea.
- Challenge weak ideas during prioritization. Start constructive, then become more critical when ranking ideas.
- Avoid implementation detail. Do not write code, file-by-file plans, GitHub issues, sprint plans, or architecture plans unless the user explicitly switches to planning/documentation outside this brainstorm flow.
- Follow the user's language. Prefer English labels in tables so the output can be reused in GitHub, docs, Cursor, Copilot, Codex, or similar tools.

## Workflow

### 1. Clarify the target area when needed

If the user has not named a specific project area, ask up to 3 questions such as:

1. What area should I focus on?
2. What kind of improvement are you looking for: feature, UX, bug prevention, simplification, DX, quality, automation, AI, or open-ended?
3. Any constraints: time, risk, backwards compatibility, customer need, or project direction?

Do not over-interview. If the user gives enough context, proceed.

### 2. Start with 5 quick hypotheses

Before inspecting deeply, provide exactly 5 initial hypotheses. Keep them short and mark them clearly as unvalidated.

Use this framing:

```text
Here are 5 early hypotheses to create momentum. I will validate or discard them after inspecting the relevant project area.
```

Use diverse idea buckets where relevant:

- User value
- Internal efficiency
- Automation / AI
- Quality / reliability
- Sales / onboarding
- Developer experience
- Simplification / removal
- Reusable platform capability

### 3. Inspect relevant project evidence

Inspect the selected area with a medium-first, deep-where-promising approach.

Start with:

- README and relevant docs
- Project config such as package files, build files, framework config, or plugin config
- Relevant routes, pages, components, services, APIs, data models, editor tooling, tests, or examples
- TODO, FIXME, known limitations, errors, brittle code, duplicated patterns, or missing test coverage
- Recent changes if available and relevant

If stack or playbook context is missing, use the `fetch-neexo-context` skill before going deeper.

Then go deeper only on areas that could support or invalidate the strongest ideas.

Record what appears to already exist, what is missing, what seems fragile, and what might be unnecessarily complex.

### 4. Generate refined ideas

After inspection, refine the initial hypotheses into evidence-based ideas. Include multiple types of improvement, not only new features:

- New features
- Improvements to existing functionality
- Simplifications or removals
- Bug-prevention ideas
- UX or onboarding improvements
- Developer experience improvements
- Quality, reliability, or testing improvements
- Automation or AI opportunities
- Reusable platform capabilities

Discard or downgrade ideas that are already implemented, unsupported by evidence, too broad, or not aligned with the selected project area.

### 5. Score every serious idea

Use the scoring rubric in `references/brainstorm-rubric.md`.

Every serious idea must include:

- Idea
- Type
- Evidence
- Already exists?
- Impact
- Effort, where 5 means low effort and 1 means high effort
- Confidence
- Strategic fit
- Reusability
- Priority

Be explicit when an idea is based on assumption rather than verified evidence.

### 6. Challenge and prioritize

After scoring, challenge weak ideas. Explain briefly why they are weaker, such as:

- Already exists
- Too much effort for uncertain value
- Weak evidence
- Poor fit for the selected project area
- Better handled later in planning mode
- Too implementation-specific for brainstorm mode

Recommend a small number of strongest directions, usually 1-3.

### 7. Produce a handoff summary

End with a concise handoff that can be copied into planning or documentation mode.

Use this structure:

```text
## Handoff Summary

Context:
Goal:
Inspected evidence:
Top ideas:
Recommended next direction:
Why this direction:
Open questions:
Ready for:
- scoped-plan (MEDIUM scope, file list + line budget)
- plan-feature-change (cross-module or HIGH risk)
- writing to /docs
```

The handoff should be decision-ready but not an implementation plan.

## Output Guidance

Prefer compact tables for scoring and short paragraphs for reasoning. Avoid long unstructured idea lists.

When the user wants to continue, offer one clear next step, such as:

```text
I can now deepen the top idea, compare the top 3, or turn the handoff into a scoped-plan or plan-feature-change session.
```

Do not claim certainty beyond the inspected evidence.