| 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
- Read the relevant files, local guidance, and recent changes.
- 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
- Identify only the unknowns that could change the design. Ask one question at a time when an answer must come from the user.
- Lead with the recommended approach. Present alternatives only when they expose a real tradeoff the user may choose differently.
- Describe the design at the level the task needs: components, data flow, failure behavior, migration, and validation. Omit irrelevant sections.
- 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.
