brain-storm git:20261012.1709cbfA

Immutable. This exact content never changes and is served at /api/v1/blob/2422e9cf3c3cda4a.

---
name: brain-storm
description: Open several fundamentally different routes for one problem fast, so the flow does not keep doing small tweaks on one path only.
---

## Debug Prefix Protocol

- When called, print this first: `[Skills: brain-storm] Follow: <rules / context constraints that really apply now>; Current step: <one-line note>`.
- If this skill clearly depends on one rule, add one more line like `[Rules: <rule>] ...`, then continue with the real work.
- The debug prefix should stay stable, short, and easy to grep.


## Method Combination and Novel-Route Design (MANDATORY when evidence map is available)

Routes are NOT limited to picking from existing methods found by `information-collector`. When the evidence map (in `.opencode/memory/features.md`) is available, brain-storm MUST actively design **novel combination routes** in addition to single-method routes. Existing methods are prior knowledge; combining them to fill gaps is innovation.

- **Read the gap analysis**: Before designing routes, read `features.md` for the method-combination gap analysis written by `information-collector`. It flags: complementary strengths (method A handles trend, method B handles seasonality), pipeline gaps (preprocessing from domain X + model from domain Y + calibration from domain Z), ensemble opportunities (uncorrelated error modes), transferable tricks (a trick from a citing paper or issue thread), and capability voids (no single method handles a specific constraint).
- **Design combination routes**: For each significant gap, design at least one combination route that addresses it. The combination must be grounded in evidence — cite which methods are being combined and why their combination is expected to be better than any component alone. Do NOT invent combinations from thin air.
- **Combination route types**:
  - **Pipeline composition**: Method A for preprocessing/decomposition → Method B for core modeling → Method C for post-processing/calibration. Each stage grounded in evidence.
  - **Ensemble / stacking**: Multiple diverse methods whose errors are known to be uncorrelated. Grounded in the error-mode analysis from evidence.
  - **Cross-domain transfer**: A method from a different domain (found via problem degradation or reframing) applied to this task, possibly with adaptation. Grounded in the analogy evidence.
  - **Hybrid architecture**: A novel architecture that combines components from multiple existing methods (e.g., attention from model A + decomposition from method B + loss function from paper C). Grounded in the component-level evidence.
  - **Trick augmentation**: An existing strong method + a trick from a citing paper, issue thread, or competitor analysis that the original did not include. Grounded in the chain-reaction evidence.
- **Combination routes are first-class citizens**: They get their own `branch_id`, `wave`, validation path, and drop conditions — same as single-method routes. Do NOT treat them as speculative extras. If the evidence map says there is a gap, the combination route is evidence-grounded, not a guess.
- **Novelty risk management**: Every combination route must explicitly state: (a) which component's evidence is strongest, (b) which component's combination effect is least certain, (c) what the cheapest validation step is to de-risk the uncertain part. This prevents combination routes from becoming untested fantasies.

## When To Use

- One problem has multiple possible solutions.
- The current path is stuck and needs an active direction change.
- Different routes need to be compared for gain, risk, and startup cost.
- One route already looks stronger, but it still cannot be collapsed directly, so same-family variants should be widened around it.
- The evidence map reveals structural gaps that no single existing method fills, so novel combination routes are needed.
- Before the main flow ends, you need to check again whether any actions, strengthening points, or rollback routes are still missing.

## Flow

- First define the core contradiction of the current problem, instead of listing ideas right away.
- Give at least 3 fundamentally different routes. The difference should show in assumptions, methods, or validation style.
- For complex tasks, do not treat these routes as a draft list where one will be chosen. Treat them as parallel branches that should stay alive. By default keep all high-value branches for the next layer first, instead of collapsing into one main line too early.
- If the task has a public leaderboard, public ranking, public solution page, or public high-score solution, the global branch set must include at least one `self-explore path` and one `public high-score reverse-absorption path`. Both stay alive by default. The second one must not be only a note.
- Every route must get a stable `branch_id` and a clear `wave`. Later `deep-reasoning`, `plan`, TODO, and `ts-critic` should all keep using those IDs.
- Every route should say: why it is feasible, what the biggest risk is, and what the first validation step is.
- Every route should also say: why it should not be dropped too early in this round, what minimum validation gate must be passed before the next wave, and what conditions trigger dropping or downgrading.
- Keep only routes that can add information. Delete small tweak branches that change surface form only.
- In the `brain-storm` stage, do not output conclusions like `recommended main route`, `main plan`, or `merge other routes into this one`. Even if one route already looks better, write it only as `current leading branch`. Do not cancel other high-value branches that have not finished first-round validation.
- Use a BFS-like push by default: let high-value branches in the same wave do first-round validation in parallel, then decide from evidence which ones stay for the next wave.
- If one branch clearly looks ahead in the current wave, do not treat that as permission to converge. Open one more recursive widening round around this `current leading branch`, and clearly create at least 2 sibling-variant branches that are in the same family but not exactly the same. Give them new `branch_id` / `wave`.
- Those recursively widened variants must also stay alive in parallel until they are compared clearly, dropped clearly, or `ts-critic` judges that their marginal information gain is already clearly low. Do not do `found a good seed -> collapse into one main line`.
- When this skill is used as the `pre-stop gate`, list at least 3 kinds of candidates again: actions that can be done now, actions that reduce risk, and rollback routes that can strongly improve quality or fix direction.
- As long as any executable candidate with information gain still exists, output `stop not allowed` and say where the next round should start.

## Output Format

- Branch map (use mermaid when needed)
- Global branch list
- Recursive-widening branch list
- Novel-combination route list (routes designed from evidence gap analysis)
- For each route
  - branch_id
  - parent_branch_id (if it came from recursive widening of a leading branch)
  - source_type (`existing-method` / `combination` / `cross-domain-transfer` / `trick-augmentation`)
  - wave
  - route number
  - core assumption
  - route focus
  - expected gain
  - main risk
  - evidence basis (which memory features / information-collector findings ground this route)
  - combination components (if source_type is combination: which methods/tricks are combined and why)
  - novelty risk (which part is most uncertain, cheapest de-risking step)
  - first validation step
  - reason to keep it alive in this round
  - gate to enter the next wave
  - drop / downgrade conditions
- Parallel strategy for the current wavefront
- Whether early merge is allowed
- Whether stop is allowed
- If not allowed, where the next round should start