/ase-meta-brainstorm

name: ase-meta-brainstorm
argument-hint: "[--help|-h] [--max-clarify|-c <num>] [--min-ideas|-i <num>] [--min-rank|-r <num>] [--max-shortlist|-s <num>] <topic>"
description: >
    Collaboratively brainstorm a topic by diverging on ideas, converging
    through clustering and scoring, and distilling a shortlist with
    a recommended direction. Use when the user wants to brainstorm,
    explore ideas, ideate, or figure out *what* to build before *how* to
    build it.
user-invocable: true
disable-model-invocation: false
effort: high

@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md @${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md @${CLAUDE_SKILL_DIR}/../../meta/ase-dialog.md @${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md

<purpose name="ase-meta-brainstorm"> Collaboratively Brainstorm a Topic </purpose>

<expand name="getopt" arg1="ase-meta-brainstorm" arg2="--max-clarify|-c=3 --min-ideas|-i=12 --min-rank|-r=7 --max-shortlist|-s=4"> $ARGUMENTS </expand>

<objective> Collaboratively brainstorm the topic <topic><getopt-arguments/></topic> by first *diverging* into a broad space of candidate ideas, then *converging* through clustering and scoring, and finally distilling a *shortlist* with a single recommended direction. </objective>

Guiding Tenets --------------

Honor the following tenets throughout the brainstorming:

• **No Assumption of Simplicity**:

Every topic goes through the full process - a one-line config change as much as a new subsystem - because the simplest-looking topics often hide the most harmful assumptions.

• **Explore Intent First**:

Understand the *purpose*, *constraints*, and *success criteria* behind the topic before generating ideas, because ideas that optimize the wrong goal are worse than no ideas.

• **Diverge Before Converge**:

Generate many candidate ideas without judging them first, because premature evaluation collapses the space before the good ideas have a chance to surface.

• **One Question at a Time**:

Ask a single, preferably multiple-choice question per dialog round, because a wall of open questions overwhelms and yields shallow answers.

• **YAGNI Ruthlessly**:

Actively prune ideas that serve speculative future needs rather than the stated purpose, because unbuilt features still cost clarity now.

• **Ground in Reality**:

Cross-check ideas against the existing code base, documented context, and your world knowledge, because an idea that contradicts what already exists is a defect, not an option.

• **Incremental Validation**:

Seek the user's confirmation at each phase boundary before advancing, because converging on a misunderstanding wastes the entire downstream effort.

<flow>

1. <step id="STEP 1: Restate Topic">

Restate the topic to be brainstormed by outputting the following <template/>:

<template> <ase-tpl-bullet-secondary/> **TOPIC**: <topic/> </template>

</step>

2. <step id="STEP 2: Clarify Intent">

Before generating any ideas, *explore the project context* (review relevant existing files, documentation, and recent changes) and determine the <m/> (<m/> = 1..<getopt-option-max-clarify/>) *essential unknowns* about the topic - the purpose, constraints, scope boundaries, and success criteria that must be pinned down for the brainstorming to be reasonably grounded.

Notice: you are intentionally constrained to just 1..<getopt-option-max-clarify/> unknowns, as too much upfront intent clarification kills the brainstorming of ideas later. So, you *MUST* reduce the clarifications of the unknowns to the absolute minimum in general and cap it at <getopt-option-max-clarify/>!

For each essential unknown to clarify, derive a short 1-3 word facet <facet-M/> and a corresponding question <question-M/> whose answer materially changes which ideas make sense at all.

1. For each <question-M/> in the iteration cycle <M/> (<M/>=1...<m/>):

1. Output the following <template/>:

<template> <ase-tpl-bullet-signal/> FACET <M/>/<m/>: **<facet-M/>**, QUESTION: **<question-M/>** </template>

2. Determine *2 to 4* grounded candidate answers <answer-M-K/> (K={1,2,3,4}) from the code base, the documented context, and your world knowledge.

3. In the following, you *MUST* *NOT* use your built-in <user-dialog-tool/> tool! Instead, you *MUST* just show a custom dialog according to the expanded `custom-dialog` definition. You *MUST* closely follow this definition.

For this interactive dialog, use header <facet-M/> and question <question-M/>, and let the user select the <answer-M/> out of the candidate answers <answer-M-K/> (leave out the answer lines of those candidate answers you have not determined):

<expand name="custom-dialog" arg1="--other"> <facet-M/>: <question-M/> <answer-M-1/>: (grounded candidate answer 1) <answer-M-2/>: (grounded candidate answer 2) [...] </expand>

4. Dispatch on the dialog <result/>:

• If <result/> is `CANCEL`:

Skip the remaining sub-steps of this iteration cycle, break out of the iteration cycle entirely, and continue directly with the outer item `2.` (cancellation handling) that immediately follows this iteration cycle `1.` within this STEP 2.

• If <result/> starts with `ERROR:`:

Ask the user interactively, without a special tool, the question <question-M/> directly and set <answer-M/> to the response of the user.

• If <result/> matches `OTHER: <text/>`:

Set <answer-M><text/></answer-M> (t