home-brainstorming

name	home-brainstorming
description	Use before non-trivial creative work when a material product or design choice is still unresolved. Clarifies purpose, constraints, success criteria, and tradeoffs before implementation. Skip when the request is trivial or already well specified.

Brainstorming Ideas Into Designs

Turn an unclear idea into a decision-ready design. Scale the process to the uncertainty; do not force a ceremony onto a task whose important choices are already settled.

Boundary

• This skill produces a design or recommendation. Do not implement unless the user also asks for implementation.
• Do not create or commit a design document unless the user requests one or the repository requires it.
• Inspect project context before asking questions. Resolve facts from files and tools when possible.
• Pause only for a choice that materially changes scope, an irreversible action, or information only the user can provide.
• When enough information is available, recommend and finish the design. Do not add approval gates between sections.

Workflow

1. Read the relevant files, local guidance, and recent changes.
2. State the work contract in compact form:
   • purpose: what progress the design should enable
   • scope: what is included and excluded
   • success: observable acceptance and verification criteria
   • constraints: compatibility, safety, cost, and operational boundaries
3. Identify only the unknowns that could change the design. Ask one question at a time when an answer must come from the user.
4. Lead with the recommended approach. Present alternatives only when they expose a real tradeoff the user may choose differently.
5. Describe the design at the level the task needs: components, data flow, failure behavior, migration, and validation. Omit irrelevant sections.
6. Separate unresolved decisions from facts to verify during implementation.

Working in Existing Codebases

• Follow existing patterns unless they cause a problem inside the requested scope.
• Include targeted structural improvements only when the requested design depends on them.
• Avoid unrelated refactoring and hypothetical extensibility.
• Prefer small units with explicit interfaces when isolation materially improves testing or change safety.

Output

Lead with the recommendation, then give:

• the design and why it fits
• meaningful tradeoffs and rejected alternatives
• acceptance and verification criteria
• unresolved user decisions, if any
• implementation-time checks that do not block the design

Visual Companion

Offer visual-companion.md only when a mockup, layout, or diagram would materially clarify a live decision. Ask once, at the point it becomes useful. If accepted, read the reference and use the browser for visual choices; keep textual requirements and tradeoffs in the conversation.