---
name: minimalist-brainstorming
description: Use when a software request is ambiguous, solution-led, over-scoped, or missing a measurable outcome, user, constraint, or explicit non-goal.
---

# Minimalist Brainstorming

Use this skill before specifying or implementing a feature when the request
contains uncertainty. The goal is a decision-ready problem statement, not a
large idea list.

## Produce

For feature or architectural work, resolve initiative.md from
<plugin-root>/templates/ before creating the consuming project's record.

Create initiative.md for feature or architectural work. For a fast change, a
concise equivalent record is enough. Capture:

- the problem and who experiences it;
- the valuable outcome;
- evidence or observations;
- constraints and behavior to preserve;
- assumptions that still need validation;
- explicit non-goals;
- the smallest demonstrable increment;
- the next decision-maker and approval gate.

## Conversation pattern

Ask one high-value question at a time. Prefer questions that remove an
assumption, reduce scope, expose a constraint, or define observable success.

Use these prompts when useful:

- Who said this must be done this way?
- What problem remains if the proposed solution is removed?
- Who needs the outcome and what decision will it improve?
- What is the smallest behavior that proves value?
- What can be postponed, merged, or deleted?
- Which existing behavior, contract, or permission must remain unchanged?

Do not turn brainstorming into an implementation plan. Do not choose libraries,
files, abstractions, or automation until the outcome and boundaries are clear.

## Gate

Stop discovery when:

- the problem can be stated without the proposed implementation;
- the outcome is observable;
- the user or decision-maker is identified;
- constraints and non-goals are explicit;
- the smallest valuable increment is defined;
- unresolved assumptions are listed.

Ask for approval of the outcome and boundaries before moving to
minimalist-specification. If the request is already clear, record that the
earlier gate was satisfied and continue without manufacturing a workshop.

## Pressure response

“Give me all the features” becomes a candidate list, not sprint scope.
“Just start coding” is a fast-route decision only when acceptance is clear.
“Use the usual architecture” requires a reason tied to the outcome.
“Do not ask questions” does not remove missing acceptance criteria; ask only the
smallest blocking question.

## Handoff

Report the initiative path, the approved outcome, the exclusions, and the next
artifact. Preserve rejected ideas when their rejection affects future decisions.