brainstorm

Collaborative Brainstorming

Turn uncertainty into a useful choice or a focused experiment. Explore only the questions that could change the design. A clear implementation request already supplies direction; act on it without manufacturing a brainstorm or approval gate.

The user's instructions take precedence over this skill's guidelines. Preserve their constraints and existing authorization. Resolve routine design details with judgment; ask only when missing information materially changes the outcome and cannot be inferred.

Choose the Work Shape

Ground the Question

Read the relevant code, artifact, or workflow and recall prior decisions. When Sibyl is configured, use its installed skill for current commands (sibyl context "<decision>" --intent plan). Memory supplies leads; inspect current evidence before reusing a volatile claim.

Name the intended experience or behavior, the constraint that matters most, and what remains unknown. Treat the user's hunch as a hypothesis worth checking, not a claim to rubber-stamp. A decisive check can confirm part of the hunch and reject the rest; report both.

Translate taste into examples and observations. For "smooth," identify the interaction and visible delay. For "gorgeous," inspect the reference and name the composition, motion, or typography worth preserving. Quantification helps where a metric represents the experience; a proxy metric does not replace the experience itself.

Distinguish explicit requirements from inferred preferences. Do not downgrade "use X" to a preference merely because the user wrote casually. If the instruction conflicts with feasibility, explain the conflict and resolve it before choosing an incompatible design.

Explore the Alternatives That Matter

The Double Diamond offers a useful rhythm: widen the problem frame, narrow it, explore solutions, choose. Revisit the frame when evidence changes it. No phase requires a separate artifact or confirmation.

Generate alternatives along meaningful dimensions: ownership of state, migration cost, runtime behavior, user effort, or reversibility. Different names for the same mechanism do not create real choice. Consider reuse, configuration, or removing the need when those paths still meet the requested outcome. Include an unconventional direction when the obvious options share an untested assumption; do not invent a wildcard to fill a slot.

Compare viable options in the dimensions relevant to this decision:

Keep ambition and mechanism separate. Simplifying the machinery should preserve the useful destination. A small implementation that proves only connectivity may miss the actual product; an elaborate one may bury it. Use expected lifetime and likely change boundaries to judge architecture, rather than equating fewer lines with better design.

Before extending a design, ask where each responsibility belongs. A decision repeated across callers may need one owner. A wrapper may instead be enforcing a valuable boundary. Remove indirection after understanding its contract, not because forwarding looks trivial.

Test the Uncertainty Before Polishing

Choose the next action by its ability to change the decision. A compatibility check, representative benchmark, or rough interaction prototype can settle more than another design paragraph.

Independent opinions can expose assumptions, but agreement is not proof. Reviewers may share training, sources, or framing. Resolve consequential disagreements through code, source material, or an experiment. State when evidence remains inconclusive.

Decide and Preserve the Reason

Recommend the best-supported direction with its principal tradeoff and the next action. Keep exploration open when that is the requested deliverable; do not force a build decision prematurely. Continue authorized work once the direction is clear. A remaining product or risk decision belongs with the user, but implementation details do not require a new consent question.

For a durable decision, record the choice, rationale, rejected alternative worth remembering, evidence, and condition that would trigger reconsideration. Preserve deliberately open decisions and user corrections verbatim when paraphrase would narrow them. Use configured project memory rather than creating duplicate decision ledgers.

Route unresolved factual questions to research, complex execution to plan, and a clear bounded change to implement. These are optional compositions, not a mandatory pipeline.

Evidence and Limits

Reviewed 2026-09-04. The Design Council's Double Diamond describes iterative divergence and convergence; it does not prescribe option counts or divide judgment between humans and models. Treat it as a design aid, not an effectiveness benchmark.

The OpenAI Astra guidance recommends explicit instruction precedence and follow-through because conflicting skill guidance can cause unnecessary pauses. Apply that to workflow clarity without assuming every host exposes the same capabilities.

Anti-Patterns

What This Skill is NOT

• A prerequisite for implementation, debugging, or routine fixes.
• A requirement to produce a spec, a fixed number of options, or a final approval question.
• A substitute for the user's product judgment or current technical evidence.