/brainstorming

name: brainstorming
description: Refine feature and sprint intent into a useful specification. Capture scope, observable criteria and material choices without repeated artifact approval ceremonies.
disable-model-invocation: true

brainstorming

Refine the agreed outcome before implementation. This is intent clarification and specification authoring, not a second permission system. The feature or sprint request is the initial authorization; ask about consequential choices not already answered, not whether an artifact may exist.

Format and caller

For artifact I/O, load `{{PLUGIN_ROOT}}/includes/artifacts.md` and select the source with `_select_authoring_route`. Retain that source identity through specification authoring.

The calling feature or sprint owns scope and the next step. A sprint may include several related features under one coherent goal. A small inline feature remains the caller's mini-spec lane. Specification authoring itself does not grant commit, publication, override, provider spending, or irreversible-operation authority.

Use relevant CONTEXT.md, tech-stack.md and security-controls.md when present; in an HTML-knowledge repository use `knowledge.py relevant <paths>` and the greenfield decomposition records instead (see `{{PLUGIN_ROOT}}/includes/knowledge.md`). Read an existing open-questions document and relevant ADR/plan headings index-first. Missing optional historical indices are not blockers. Preserve real decisions while distinguishing an accepted decision from implemented or released behavior.

When the request selects an existing work ID, first read it through the selected owner with `work.py context <work_id>` as described in the knowledge include. Reuse its exact spec/plan bindings and stated intent; inspect the current source and ask only about consequential gaps. A same-title item is not an identity match, and a work context is not evidence that attached checks ran.

Recorded intent and consequential conflicts

Use an index-first recorded-intent read to avoid asking about settled choices. This pre-flight is exempt from the read-or-STOP rule when optional project history is absent: **intent: silent — no decomposition record**. Do not manufacture a plan or an approval to fill that gap.

If a proposed solution resurrects a capability `plans/02` records as deferred, identify the original reason and any stated re-evaluation trigger, then fork to ask only when the *outcome* would materially change. An explicit current owner steer can settle that fork; an ordinary implementation detail cannot silently reverse a recorded deferral.

A candidate that contradicts an accepted ADR must be **surfaced WITH the ADR citation, never silently dropped**. A recommended outcome change is paired with a supersession fork via `/adr` instead of pretending the old decision never existed. If the contradiction is the only sane approach, that IS the fork: show the choice and consequence to the owner once, respecting an already recorded superseding instruction. A referenced ADR is not a new permission token for safe, in-scope investigation or implementation.

Phase 1 - Frame

State the problem, observable result, intended scope and explicit exclusions. Respect what the user already requested. If a record conflicts with new intent, identify the material decision and which work it affects; do not automatically create another approval round for ordinary method choices.

Phase 2 - Select a viable approach

Consider genuine trade-offs where they matter, recommend a suitable approach and explain why. Do not manufacture straw alternatives. Reversible implementation methods remain agent-owned within the agreed outcome. Ask for a user ruling on an unresolved, consequential product choice, not on every viable implementation detail.

**Never manufacture alternatives.** When only one sane approach exists, say so in one line and say why; that path runs no SMARTS comparison and adds no SMARTS table.

**SMARTS on a material choice.** Only when two or more materially plausible approaches exist, run a SMARTS comparison per `{{PLUGIN_ROOT}}/includes/smarts/core.md` inline before recommending one. Bound it to the context-envelope dimensions that could differentiate the approaches, mark missing evidence `Unknown` with its missing observation, and surface a decision-critical `Unknown` before selecting. If every candidate carries one, pause the selection until the missing observation is resolved or the user rules. The comparison dispatches no grader or scout, performs no bulk read of `plans/` or `decisions/`, and loads `{{PLUGIN_ROOT}}/includes/smarts/lenses.md` only when a verdict turns on a consideration the core summaries do not settle. Name cost, schedule, team-skill, vendor or stakeholder constraints alongside the result; they never become a seventh lens. Apply the core's priority order when lenses conflict; a tie without explicit priority evidence goes to the user. An explicit request for a full SMARTS read changes only the presentation depth — the full option-by-option table — with no new command and no change to decision authority.

**Record the rationale.** When the comparison ran, write the decisive lenses, any `Unknown` with its missing observation, the non-SMARTS constraints and the selection reason into the spec's `SEC-SMARTS` section, or the `## SMARTS design rationale` section of a Markdown spec. A single-approach choice records only its one-line statement there.

Review applicable ADRs and explicit exclusions. A real conflicting architecture decision goes to its owner. Mentioning a protected file does not by itself restart the entire feature interview.

Phase 3 - Make acceptance observable

Turn intended scope into specific criteria: input or trigger, expected behavior, and relevant failure/boundary condition. Check integration risks and ask: **if every criterion passed, what would still be broken?** For meaningful behavior changes, plan one or more focused tests against