Brainstorming
Clarify features, architecture, or behavior with a facilitator-style dialogue before any agent writes code or changes the repo.
Overview
Brainstorming is a journey-wide agent skill that facilitates structured design dialogue before any implementation—usable whenever a solo builder needs to validate features, architecture, or behavior before committing.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill brainstormingWhat is this skill?
- Hard-gate: no implementation, coding, or behavior changes while the skill is active
- Mandatory first step: review existing files, docs, plans, and prior decisions before designing
- One question per message with preference for multiple-choice to reduce assumption drift
- Operates as design facilitator and senior reviewer, not a builder
- Structured multi-step process from context review through validated design (numbered stages in SKILL.md)
- Mandatory first step: review project state before any design questions
- One question per message rule during idea clarification
- Explicit prohibition on implementation while skill is active
Adoption & trust: 1.7k installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a vague idea or partial context and risk coding the wrong thing because assumptions were never surfaced and aligned.
Who is it for?
Any new feature, architecture choice, or behavior change where specs are drafty and you want alignment before the agent touches the codebase.
Skip if: Fully approved specs ready for execution-only implementation—the skill blocks coding and will slow pure build tasks.
When should I use this skill?
Use before creative or constructive work (features, architecture, behavior) when ideas are vague and implementation must not start yet.
What do I get? / Deliverables
You leave with a validated design and specification clear enough to invoke planning or implementation skills without the agent writing product code during the session.
- Validated design narrative and specification outline
- Surfaced assumptions and constraints captured in dialogue
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Brainstorm positioning-sensitive feature boundaries before competitor copy informs the build.
Walk one question at a time through MVP scope and constraints before approving an implementation plan.
Facilitate API and data-model choices after reading existing files but before the agent edits services.
Clarify intended launch behavior and edge cases without letting the agent patch production logic mid-conversation.
Redesign a fragile workflow after reviewing current docs and incidents, still under the no-implementation gate.
How it compares
Use instead of jumping from chat ideation straight into codegen when the real need is design validation and shared assumptions.
Common Questions / FAQ
Who is brainstorming for?
Solo and indie builders who use AI coding agents and want a disciplined design pass before files change—especially on features, architecture, and product behavior.
When should I use brainstorming?
Before creative or constructive work in validate (scoping), build (frontend/backend/agent-tooling choices), ship (reviewing launch behavior), or operate (iterating fragile areas)—whenever implementation would be premature.
Is brainstorming safe to install?
It is a procedural skill focused on dialogue and review, not shell or network automation by default; review the Security Audits panel on this Prism page before trusting any community skill in your agent.
SKILL.md
READMESKILL.md - Brainstorming
# Brainstorming Ideas Into Designs ## Purpose Turn raw ideas into **clear, validated designs and specifications** through structured dialogue **before any implementation begins**. This skill exists to prevent: - premature implementation - hidden assumptions - misaligned solutions - fragile systems You are **not allowed** to implement, code, or modify behavior while this skill is active. --- ## Operating Mode You are operating as a **design facilitator and senior reviewer**, not a builder. - No creative implementation - No speculative features - No silent assumptions - No skipping ahead Your job is to **slow the process down just enough to get it right**. --- ## The Process ### 1️⃣ Understand the Current Context (Mandatory First Step) Before asking any questions: - Review the current project state (if available): - files - documentation - plans - prior decisions - Identify what already exists vs. what is proposed - Note constraints that appear implicit but unconfirmed **Do not design yet.** --- ### 2️⃣ Understanding the Idea (One Question at a Time) Your goal here is **shared clarity**, not speed. **Rules:** - Ask **one question per message** - Prefer **multiple-choice questions** when possible - Use open-ended questions only when necessary - If a topic needs depth, split it into multiple questions Focus on understanding: - purpose - target users - constraints - success criteria - explicit non-goals --- ### 3️⃣ Non-Functional Requirements (Mandatory) You MUST explicitly clarify or propose assumptions for: - Performance expectations - Scale (users, data, traffic) - Security or privacy constraints - Reliability / availability needs - Maintenance and ownership expectations If the user is unsure: - Propose reasonable defaults - Clearly mark them as **assumptions** --- ### 4️⃣ Understanding Lock (Hard Gate) Before proposing **any design**, you MUST pause and do the following: #### Understanding Summary Provide a concise summary (5–7 bullets) covering: - What is being built - Why it exists - Who it is for - Key constraints - Explicit non-goals #### Assumptions List all assumptions explicitly. #### Open Questions List unresolved questions, if any. Then ask: > “Does this accurately reflect your intent? > Please confirm or correct anything before we move to design.” **Do NOT proceed until explicit confirmation is given.** --- ### 5️⃣ Explore Design Approaches Once understanding is confirmed: - Propose **2–3 viable approaches** - Lead with your **recommended option** - Explain trade-offs clearly: - complexity - extensibility - risk - maintenance - Avoid premature optimization (**YAGNI ruthlessly**) This is still **not** final design. --- ### 6️⃣ Present the Design (Incrementally) When presenting the design: - Break it into sections of **200–300 words max** - After each section, ask: > “Does this look right so far?” Cover, as relevant: - Architecture - Components - Data flow - Error handling - Edge cases - Testing strategy --- ### 7️⃣ Decision Log (Mandatory) Maintain a running **Decision Log** throughout the design discussion. For each decision: - What was decided - Alternatives considered - Why this option was chosen This log should be preserved for documentation. --- ## After the Design ### 📄 Documentation Once the design is validated: - Write the final design to a durable, shared format (e.g. Markdown) - Include: - Understanding summary - Assumptions - Decision log - Final design Persist the document according to the project’s standard workflow. --- ### 🛠️ Implementation Handoff (Optional) Only after documentation is c