Brainstorming Ideas Into Designs

---

name: brainstorming description: Structured design facilitation that transforms vague ideas into validated designs through disciplined reasoning. Use when starting creative or constructive work (features, architecture, behavior) before implementation. tags: [design, facilitation, ideation, requirements]

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.

Anti-Patterns

• Jumping to solutions before understanding the problem
• Asking multiple questions at once (overwhelms, reduces quality)
• Skipping the Understanding Lock gate
• Designing without explicit non-goals
• Proposing only one approach (no alternatives considered)
• Proceeding to implementation without documented decisions

References

• Design Thinking (IDEO)
• YAGNI Principle