brainstorming

Automation & Intégrations

>

Documentation

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.

Utiliser l'Agent brainstorming - Outil & Compétence IA | Skills Catalogue | Skills Catalogue