Brainstorm

Unified runtime invocation

Resolve the plugin root from this loaded file: SKILL.md is at <plugin-root>/skills/<skill-name>/SKILL.md. Invoke only python3 "<plugin-root>/coordinator.py" and send one bounded JSON routing request on EOF-delimited stdin, without a PTY. Use the Python invocation example in the Routing request section in <plugin-root>/README.md and the co-packaged manifest's signed wire_contract; never invent fields or provider actions. Supply one caller-defined work unit per independently useful deliverable, with this skill's logical action and a bounded opaque payload. Use depends_on only for actual dependencies. Honor an operator-named provider with explicit_target. For an authorized independent review or governance task without an operator-named provider, also use that field to bind the caller-verified distinct reviewer selected by the caller or designated by the workflow. Carry the same target into planning and live dispatch; verify returned native lineage before accepting independence. Otherwise use normal untargeted routing. Choose quality and effort for the workload; include context/output token estimates when known. Read the current manifest digest and actual cwd device/inode; do not copy example values. The runtime owns its timeout; do not wrap it in a shorter fixed timeout. Repository identity, source-head verification, disposable copies, patch capture, and cleanup remain caller-owned where applicable. The shim runs standalone from the installed plugin and transports the routing client's bounded result without semantic interpretation. Never discover a provider executable, reconstruct a raw command, or replay, retry, or fail over a consumed work unit. Provider status, terminal records, receipts, telemetry, and other structured fields are optional diagnostics; none is a content-availability gate. Preserve every returned content record or recovered partial response and interpret it with ordinary model reasoning. Never synthesize approval, authority, or a receipt from process exit or missing diagnostics. A planning-only request sets dispatch_requested=false; a live request sets it true and consumes at most one provider attempt per work unit. Planning reports route eligibility, not live availability or authentication. Report a caller/client failure at that layer; provider state remains unknown unless native evidence establishes it. Content availability and each work unit's execution_status are separate facts.

Brainstorm — divergent ideation with a selected partner

Brainstorming widens the option space before convergence and decisions. A selected brainstorming partner may offer different priors or surface options the primary did not consider. No family difference is assumed or required: same-family or unknown-lineage contributions remain available as clearly labelled advisory ideation, not independent governance evidence.

When to use

Use this skill when one or more of the following are true:

• The user explicitly asks for it — "brainstorm with the reviewer," "let's ideate," "what are some options," "think this through with the reviewer," "thinking partner," "give me alternatives," "spitball this with the reviewer."
• The user poses an open-ended question with no obviously-correct answer — "what could we do about X," "how should we frame Y," "what are some ways to Z."
• The problem is early-stage and exploratory — naming, positioning, structuring, organizational design, hypothesis generation, methodology choice, candidate-feature-set generation.
• the active primary has already proposed one approach to an open-ended question and the user is weighing whether to commit. Surface alternatives rather than defending the existing proposal.
• The user appears stuck in one line of thinking on an open-ended problem and an outside perspective or differing priors could break the rut. Offer the brainstorm even if they did not ask — but only when the problem is genuinely open-ended; do not propose brainstorming during routine fact-finding, debugging, or step-by-step execution work.

When to skip

Skip this skill when:

• The question has a single correct answer that a quick lookup would resolve. Call python3 "<plugin-root>/coordinator.py" directly for fact-finding.
• The user is converging, not diverging — they have a few candidates and need to choose one. Brainstorming at this stage is decision-avoidance.
• The artifact under consideration is high-stakes and the user wants critique, not more options. Use second-opinion instead.
• The user has already brainstormed three times this cycle and is asking for a fourth round in the same direction. The bottleneck is decision-making, not idea-shortage.

Procedure

1. Frame the problem as a precise question

Vague prompts produce vague output. "Help me name the product" is bad; "I am naming a {what it does} for {who it's for}; the desired tone is {tone}; what are 15 candidate names spanning literal-descriptive to abstract-evocative?" is good. The reframe forces the user to surface constraints they have been carrying implicitly — which makes the brainstorm output sharper.

If the user's question is too vague to call the tool productively, ask one targeted clarifying question first. Do not invent the constraints yourself.

2. Invoke python3 "<plugin-root>/coordinator.py" with quality_profile='economical' and effort_class='minimal'

Divergent generation favors throughput over depth — economical quality with minimal effort through an eligible provider is the default. Use frontier quality with maximum effort through an eligible provider only for highly nuanced creative work where reasoning depth on each candidate idea is more valuable than candidate breadth.

The routing contract accepts no brainstorm-specific fields. Put the following as labeled sections inside the work unit's opaque prompt and dispatch only through an advertised read-only advisory capability. If the native route is unavailable, report it; do not invent routing fields or reconstruct a provider invocation:

• prompt — the framed problem statement.
• domain — the subject-matter area (e.g., "product naming," "experimental design," "audit-finding mitigation").
• constraints — the must-haves and must-avoids (audience, tone, budget, regulatory bounds, scope limits).
• existingContext — what the active primary or the user has already tried, decided, or ruled out (so the brainstorm does not waste turns retreading).
• ideaCount — how many candidates to generate (default 12 is a reasonable starting point; raise for very broad option spaces, lower for tightly-constrained ones).
• methodology — see § Methodology selection below; default auto lets the tool pick.
• includeAnalysis — whether the tool should produce its own grouping/analysis alongside the ideas; default true is usually right, but turn off if you intend to do the synthesis yourself in step 4.

Request a numbered list with one candidate per line as presentation guidance, not as a runtime gate. Preserve and synthesize any nonempty response even when its formatting differs.

3. Ask for variation along axes, not a flat list

A flat list of 12 ideas often collapses to 3 clusters of variants. Force divergence by naming the axes the candidates should span. Examples:

• "Span conservative ↔ ambitious and technical ↔ user-facing — give me at least one candidate in each of the four quadrants."
• "Generate three candidates each at: low-cost / medium-cost / high-cost; immediate-deploy / six-month / two-year."
• "Surface candidates from at least four different methodologies (SCAMPER, design-thinking, lateral-thinking, first-principles)."

Axes-based prompts produce systematic coverage of the option space; flat prompts produce clustering around the most obvious solution category.

4. Do not pre-filter; let the weird ones through

If the tool returns three or four ideas that seem strange or impractical, do not silently drop them before showing the user. Pre-filtering at this stage destroys the value of the brainstorm — the user is often the one best positioned to spot the unexpected gem. If the list is uniformly safe or uniformly variations on the same theme, say so. Show and synthesize the full raw response. Do not issue a follow-up automatically. Only after the caller selects a cluster or explicitly authorizes a new request may you request a more divergent batch.

5. Synthesize, then close

Do not just relay the raw list. When you present the result to the user:

• Group the candidates into 2–4 thematic clusters or methodological families. Name each cluster.
• Surface 1–2 unexpected ones that did not fit a cluster — flag them explicitly as "the outliers worth a look."
• Hand the user a question — "which cluster is most interesting?" or "do any of these change how you are framing the problem?" — that moves them toward convergence.

A brainstorm that ends with a raw list dump puts the synthesis work back on the user; this skill is not done until the synthesis is done.

Methodology selection

Put a methodology instruction inside the prompt. It is not a coordinator field. Default auto lets the selected role choose; explicit selection is useful when you want a specific style of divergence. Brief guide:

Iteration

A single brainstorm round may reveal useful next directions. After presenting and synthesizing the first round, ask which cluster interests the caller. Only after the caller selects a cluster or explicitly authorizes a new request:

• Pick the cluster that surfaces the most interest and request 5–10 more candidates in that direction. (This is convergence-via-divergence — narrowing the option space by going wider in the chosen sub-space.)
• Pick the cluster that feels weakest and ask "what would it take to make this category actually viable?" — the constraints that surface often illuminate the real problem.
• For follow-up clarification or fact-checking of a specific candidate, call python3 "<plugin-root>/coordinator.py" directly with the focused question. Reserve python3 "<plugin-root>/coordinator.py" for the divergent passes.

Iteration ends when the user converges on a direction or explicitly steps out of ideation into decision-making. Do not keep generating because more is always available.

Examples across domains

Brainstorming is broadly applicable. A representative sample of where divergent ideation pays off:

Pick examples from the user's domain when explaining the brainstorm scope. Match where they are — generic framing produces generic interest.

Anti-patterns

• Asking the reviewer to decide. Brainstorming is divergent. Asking "which is best?" pushes the model into a synthesis it has no business making for the user — and trains the user to outsource judgment.
• Hiding a lack of divergence. The first list often clusters around the most obvious solution category. Say so, show the list, and let the caller decide whether another divergent request is worthwhile.
• Mixing convergence into the brainstorm prompt. "Give me 10 options ranked by likelihood of success" is a different request — and a worse one for this stage. Generate first, evaluate later. If the user genuinely wants ranking, do a second-pass convergent invocation, not a mixed-mode first pass.
• Using frontier/maximum reflexively because the topic feels weighty. Divergent generation favors economical/minimal for more candidates and lower latency. Reserve frontier/maximum for cases where each candidate genuinely needs reasoning depth (e.g., generating hypothetical contract clauses where each one needs internal coherence, not just one-line bullet points).
• Pre-filtering the weird ones before showing the user. The strange-looking candidate is often where the gem hides. Show everything; let the user prune.
• Dumping the raw list and calling it done. Synthesis (cluster, name the clusters, flag outliers, hand the user a forward question) is the user-facing deliverable. The list itself is intermediate.
• Running this on a question the user has already brainstormed three times. At that point the bottleneck is decision-making, not idea-shortage. Say so and pivot to convergence support.
• Brainstorming a question that has a single right answer. "What is the capital of France" does not need a divergent thinking partner. Route fact-finding through python3 "<plugin-root>/coordinator.py" directly.