Brainstorm
Turn fuzzy product ideas into a validated design brief with clarified requirements and trade-offs before you plan or write code.
Overview
Brainstorm is a journey-wide agent skill that turns ambiguous ideas into validated design briefs through structured dialogue—usable whenever a solo builder needs to clarify scope before committing.
Install
npx skills add https://github.com/buiducnhat/agent-skills --skill brainstormWhat is this skill?
- Structured workflow: gather project context, clarify requirements, explore alternatives, produce a design brief
- Reads docs/SUMMARY.md first and loads only task-relevant detail and code-standard docs
- Sequential targeted questions on objective, scope, constraints, and success criteria
- Explores multiple approaches with explicit trade-offs before committing
- Outputs artifacts or a handoff ready for planning—not ad-hoc chat conclusions
- Four-step workflow: gather context, clarify requirements, explore alternatives, produce design brief
Adoption & trust: 516 installs on skills.sh; 48 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a rough idea or feature ask but unclear requirements, overlapping options, and no trusted brief to hand to planning or implementation.
Who is it for?
Solo founders and indie devs starting features, refactors, or integrations where multiple designs are viable and stakes warrant explicit alignment.
Skip if: Work where an approved spec already exists and you only need execution, or trivial one-line changes with no design risk.
When should I use this skill?
Requirements are unclear, multiple approaches are possible, or you need a validated design brief before planning or coding.
What do I get? / Deliverables
You get a validated design brief with scoped requirements, constraints, and trade-offs documented—ready for a dedicated planning skill or implementation pass.
- Validated design brief with scope, constraints, and success criteria
- Documented alternatives with trade-offs for review
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Compare two monetization shapes for a micro-SaaS before you validate pricing on a landing page.
Bound MVP features and success metrics for an API integration the user only described in one sentence.
Choose between monolith endpoints versus a worker queue when refactoring a high-traffic path.
Weigh staged rollout versus big-bang release when launch risk affects support load.
Design an onboarding experiment with clear guardrails before engineering builds funnels.
How it compares
Use instead of jumping straight from chat brainstorming into coding without a recorded brief.
Common Questions / FAQ
Who is brainstorm for?
Solo and indie builders facing ambiguous requirements who want a structured design conversation anchored in their repo docs and conventions.
When should I use brainstorm?
At Idea when framing a new product direction, at Validate when scoping a feature, at Build before large refactors, at Ship when launch options need trade-offs, and anytime multiple approaches need comparison before planning.
Is brainstorm safe to install?
It guides dialogue and may read project docs; review the Security Audits panel on this Prism page before installing from the repository.
SKILL.md
READMESKILL.md - Brainstorm
# Brainstorm ## Overview Use this skill to convert rough ideas into clear, reviewable design outputs through structured dialogue. The goal is to: 1. Clarify requirements and constraints 2. Explore alternatives with trade-offs 3. Produce a concrete, validated design brief in artifacts or a handoff to planning ## Workflow ### Step 1: Gather Project Context Load only the project context relevant to the current idea: - If `docs/SUMMARY.md` exists, read it first. - Load only task-relevant detail docs. - Prioritize `Code Standard` docs for implementation conventions. - If docs conflict with code or user intent, use the available input/question tool before broad changes. Also check key implementation files relevant to the idea and note constraints from existing architecture, dependencies, and conventions. Keep this pass focused. Only gather what is needed for the current idea. ### Step 2: Clarify Requirements Ask targeted questions sequentially to remove ambiguity with input/question tool: - Focus on: - Objective and user value - Scope boundaries - Constraints (technical, UX, performance, timeline) - Success criteria - Non-goals Do not jump to implementation details too early. ### Step 3: Explore Approaches Propose 2-5 viable approaches. For each approach, include: - Short summary - Pros - Cons / risks - Complexity estimate - Recommended use conditions Lead with your recommended option and explain why it best fits the project context and constraints. After presenting all approaches, use input/question tool to let the user pick their preferred approach. List the summary options. Example: 1. Approach A, short summary 2. Approach B, short summary 3. Approach C, short summary 4. Other (please specify) with the tag added for the recommended approach to guide the user. ### Step 4: Present the Design Incrementally Once requirements are clear, present the design incrementally in logical phases (about 200-300 words per phase) to avoid overwhelming the user. - **Phase 1: Foundation** - Problem framing, goals, and proposed architecture/flow. - **Phase 2: Technical Details** - Data model, interfaces, error handling, and edge cases. - **Phase 3: Delivery** - Testing/verification strategy and rollout considerations (if applicable). After presenting **each phase**, use input/question tool immediately to ask whether to: 1. Proceed to the next phase 2. Adjust the current phase 3. Revisit a previous phase ### Step 5: Close the Loop After you and the user have worked through requirements and the design is validated, determine the next actions. 1. Use input/question tool to present the user with three high-level next actions: - "Write plan immediately (in current context)" - skip the artifact step and move straight to a `write-plan` handoff. - "Write artifacts" - continue by authoring the brainstorm documents described in Step 6. - "Implement immediately (skip design artifacts and planning)" - if the design is very clear and low-risk, the user may choose to skip both artifacts and planning and move straight to implementation. - "End session (already provided enough information for user)" - stop; the conversation has produced enough insight for now. 2. If the user picks **Write artifacts**, proceed to Step 6. Once the draft artifacts exist, use input/question tool again to validate them with options: - "Write plan with current artifacts, context" - "End session - artifacts are sufficient for now" - "Need changes" (free-form text) - collect the feedback, revise the artifacts, and re-ask. 3. If the user picked **Write plan immediately**, initiate a h