# Brainstorming > Use before creative or constructive work (features, architecture, behavior). Transforms vague ideas into validated designs through disciplined reasoning and collaboration. - Skill: `techwavedev/brainstorming` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add techwavedev/brainstorming` - Raw SKILL.md: https://api.skillmd.com/api/skills/techwavedev/brainstorming/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: techwavedev (https://skillmd.com/u/techwavedev) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/techwavedev/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 complete, ask: > “Ready to set up for implementation?” If yes: - Create an explicit implementation plan - Isolate work if the workflow supports it - Proceed incrementally --- ## Exit Criteria (Hard Stop Conditions) You may exit brainstorming mode **only when all of the following are true**: - Understanding Lock has been confirmed - At least one design approach is explicitly accepted - Major assumptions are documented - Key risks are acknowledged - Decision Log is complete If any criterion is unmet: - Continue refinement - **Do NOT proceed to implementation** --- ## Key Principles (Non-Negotiable) - One question at a time - Assumptions must be explicit - Explore alternatives - Validate incrementally - Prefer clarity over cleverness - Be willing to go back and clarify - **YAGNI ruthlessly** --- If the design is high-impact, high-risk, or requires elevated confidence, you MUST hand off the finalized design and Decision Log to the `multi-agent-brainstorming` skill before implementation. ## When to Use This skill is applicable to execute the workflow or actions described in the overview. --- ## AGI Framework Integration > **Adapted for [@techwavedev/agi-agent-kit](https://www.npmjs.com/package/@techwavedev/agi-agent-kit)** > Original source: [antigravity-awesome-skills](https://github.com/sickn33/antigravity-awesome-skills) ### Memory-First Protocol Retrieve prior Architecture Decision Records (ADRs), trade-off analyses, and system design rationale. Critical for maintaining consistency across long-running projects. ```bash # Check for prior architecture/design context before starting python3 execution/memory_manager.py auto --query "architecture decisions and trade-off analysis for Brainstorming" ``` ### Storing Results After completing work, store architecture/design decisions for future sessions: ```bash python3 execution/memory_manager.py store \ --content "Architecture: event-driven microservices with CQRS, Pulsar for messaging, Qdrant for semantic search" \ --type decision --project \ --tags brainstorming architecture ``` ### Multi-Agent Collaboration Broadcast architecture decisions to ALL agents so implementation stays aligned with the chosen patterns. ```bash python3 execution/cross_agent_context.py store \ --agent "" \ --action "Completed architecture review — ADR documented, trade-offs analyzed, team aligned" \ --project ``` ### Control Tower Coordination Register architecture tasks in the Control Tower so all agents across machines know the current system design and constraints.