Maison

Skill

Productivité et flux de travail

brainstorming

obra/superpowers

Il anime un dialogue collaboratif visant à transformer les idées en projets et cahiers des charges aboutis avant le début de toute mise en œuvre.

...Développer tout

Heure mise à jour 3 septembre 2026

# collaboration # requirements # planning # specification # design doc

Brainstorming Des idées aux créations

Contribuez à transformer les idées en conceptions et spécifications abouties grâce à un dialogue collaboratif naturel.

Commencez par comprendre le contexte actuel du projet, puis posez des questions une à une pour affiner l'idée. Une fois que vous comprenez ce que vous êtes en train de créer, présentez la conception et obtenez l'accord de l'utilisateur.

Anti-modèle : « C'est trop simple pour nécessiter une conception »

Chaque projet passe par ce processus. Une liste de tâches, un utilitaire à fonction unique, une modification de configuration… tous sans exception. C’est dans les projets « simples » que les hypothèses non vérifiées entraînent le plus de travail inutile. La conception peut être succincte (quelques phrases pour les projets vraiment simples), mais vous DEVEZ la présenter et obtenir une validation.

Liste de contrôle

Vous DEVEZ créer une tâche pour chacun de ces éléments et les réaliser dans l’ordre :

Explorer le contexte du projet — vérifier les fichiers, la documentation, les commits récents
Proposez le support visuel au moment opportun — PAS dès le départ. La première fois qu’une question serait véritablement plus claire sous forme visuelle que sous forme écrite, proposez-le alors (dans un message dédié) ; une fois approuvé, l’onglet du navigateur s’ouvre pour vous. Si aucune question visuelle ne se pose jamais, ne le proposez jamais. Voir la section « Support visuel » ci-dessous.
Posez des questions de clarification — une à la fois, afin de comprendre l’objectif, les contraintes et les critères de réussite
Proposez 2 à 3 approches — en précisant les compromis et en donnant votre recommandation
Présentez la conception — par sections classées selon leur complexité, obtenez l’accord de l’utilisateur après chaque section
Rédigez le document de conception — enregistrez-le dans docs/superpowers/specs/AAAA-MM-JJ--design.md et validez-le
Auto-révision du cahier des charges — vérification rapide en ligne des espaces réservés, des contradictions, des ambiguïtés et du périmètre (voir ci-dessous)
Révision des spécifications par l’utilisateur — demandez à l’utilisateur de relire le fichier de spécifications avant de poursuivre
Passage à la mise en œuvre — utiliser la compétence « writing-plans » pour créer un plan de mise en œuvre

Déroulement du processus

digraph brainstorming {
    « Explorer le contexte du projet » [shape=box];
    « Poser des questions de clarification » [shape=box];
    « Proposer 2 à 3 approches » [shape=box];
    « Présenter les sections de conception » [shape=box];
    « L’utilisateur approuve-t-il la conception ? » [shape=diamond];
    « Rédiger le document de conception » [shape=box];
    « Auto-révision du cahier des charges\n(corrections en ligne) » [shape=box];
    « L’utilisateur révise-t-il le cahier des charges ? » [shape=diamond];
    « Faire appel à la compétence « plans de rédaction » » [shape=doublecircle];

    « Explorer le contexte du projet » -> « Poser des questions de clarification » ;
    « Poser des questions de clarification » -> « Proposer 2 à 3 approches » ;
    « Proposer 2 à 3 approches » -> « Présenter les sections de conception » ;
    « Présenter les sections de conception » -> « L’utilisateur approuve-t-il la conception ? » ;
    « L’utilisateur approuve-t-il la conception ? » -> « Présenter les sections de conception » [label="non, réviser"];
    « L’utilisateur approuve-t-il la conception ? » -> « Rédiger le document de conception » [label="oui"];
    « Rédiger le document de conception » -> « Auto-révision du cahier des charges\n(corrections en ligne) »;
    « Auto-révision du cahier des charges\n(corrections en ligne) » -> « L’utilisateur valide-t-il le cahier des charges ? »;
    « L’utilisateur révise-t-il le cahier des charges ? » -> « Rédiger le document de conception » [label="modifications demandées"];
    « L’utilisateur révise-t-il le cahier des charges ? » -> « Appeler la compétence writing-plans » [label="approuvé"];
}

L'état terminal consiste à appeler la compétence « writing-plans ». N'appelez PAS les compétences « frontend-design », « mcp-builder » ni aucune autre compétence d'implémentation. La SEULE compétence que vous appelez après « brainstorming » est « writing-plans ».

Le processus

Comprendre le principe :

Vérifiez d’abord l’état actuel du projet (fichiers, documentation, commits récents)
Avant de poser des questions détaillées, évaluez la portée : si la demande décrit plusieurs sous-systèmes indépendants (par exemple, « créer une plateforme avec un chat, un stockage de fichiers, une facturation et des analyses »), signalez-le immédiatement. Ne perdez pas de temps à poser des questions pour affiner les détails d’un projet qui doit d’abord être décomposé.
Si le projet est trop vaste pour tenir dans un seul cahier des charges, aidez l’utilisateur à le décomposer en sous-projets : quels sont les éléments indépendants, comment sont-ils liés, dans quel ordre doivent-ils être développés ? Réfléchissez ensuite au premier sous-projet en suivant le processus de conception habituel. Chaque sous-projet suit son propre cycle : cahier des charges → planification → mise en œuvre.
Pour les projets dont la portée est appropriée, posez les questions une par une afin d’affiner l’idée
Privilégiez les questions à choix multiples lorsque c’est possible, mais les questions ouvertes conviennent également
Une seule question par message : si un sujet nécessite d’être approfondi, divisez-le en plusieurs questions
Concentrez-vous sur la compréhension : objectif, contraintes, critères de réussite

Exploration des approches :

Proposez 2 à 3 approches différentes, en soulignant leurs avantages et leurs inconvénients
Présentez les options sous forme de dialogue, en indiquant votre recommandation et votre raisonnement
Commencez par l'option que vous recommandez et expliquez pourquoi

Présentation de la conception :

Une fois que vous estimez avoir bien compris ce que vous êtes en train de créer, présentez la conception
Adaptez la longueur de chaque section à sa complexité : quelques phrases si elle est simple, jusqu’à 200-300 mots si elle est nuancée
Après chaque section, demandez si tout semble correct jusqu’à présent
Abordez les points suivants : architecture, composants, flux de données, gestion des erreurs, tests
Soyez prêt à revenir en arrière et à apporter des précisions si quelque chose ne semble pas clair

Concevez en privilégiant l’isolation et la clarté :

Décomposez le système en unités plus petites ayant chacune un objectif clair, communiquant via des interfaces bien définies, et pouvant être comprises et testées indépendamment
Pour chaque unité, vous devriez pouvoir répondre aux questions suivantes : que fait-elle, comment l'utilise-t-on et de quoi dépend-elle ?
Quelqu’un peut-il comprendre ce que fait une unité sans en lire le fonctionnement interne ? Pouvez-vous modifier son fonctionnement interne sans perturber les utilisateurs ? Si ce n’est pas le cas, les limites doivent être revues.
Des unités plus petites et bien délimitées sont également plus faciles à manipuler : vous comprenez mieux le code lorsque vous pouvez en saisir le contexte dans son ensemble, et vos modifications sont plus fiables lorsque les fichiers sont ciblés. Lorsqu'un fichier devient trop volumineux, c'est souvent le signe qu'il en fait trop.

Travailler sur des bases de code existantes :

Explorez la structure actuelle avant de proposer des modifications. Suivez les modèles existants.
Lorsque le code existant présente des problèmes qui affectent le travail (par exemple, un fichier devenu trop volumineux, des limites floues, des responsabilités entremêlées), intégrez des améliorations ciblées dans la conception — à l’image d’un bon développeur qui améliore le code sur lequel il travaille.
Ne proposez pas de refactorisation hors sujet. Restez concentré sur ce qui sert l’objectif actuel.

Après la conception

Documentation :

Rédigez la conception validée (spécification) dans le fichier docs/superpowers/specs/AAAA-MM-JJ--design.md
- (Les préférences de l’utilisateur concernant l’emplacement du cahier des charges prévalent sur cette valeur par défaut)
Utilisez la compétence « éléments de style : rédiger de manière claire et concise » si elle est disponible
Validez le document de conception dans git

Auto-révision du cahier des charges : Après avoir rédigé le cahier des charges, relisez-le avec un regard neuf :

Recherche des éléments provisoires : y a-t-il des mentions « À déterminer », « À faire », des sections incomplètes ou des exigences vagues ? Corrigez-les.
Cohérence interne : certaines sections se contredisent-elles ? L’architecture correspond-elle aux descriptions des fonctionnalités ?
Vérification de la portée : le document est-il suffisamment ciblé pour un seul plan de mise en œuvre, ou doit-il être décomposé ?
Vérification des ambiguïtés : une exigence pourrait-elle être interprétée de deux façons différentes ? Si oui, choisissez-en une et précisez-la clairement.

Corrigez les problèmes directement dans le texte. Inutile de procéder à une nouvelle révision : contentez-vous de corriger et passez à la suite.

Vérification par l’utilisateur : Une fois le cycle de révision des spécifications terminé, demandez à l’utilisateur de relire les spécifications écrites avant de poursuivre :

« Le cahier des charges a été rédigé et validé sur . Veuillez les relire et me faire savoir si vous souhaitez y apporter des modifications avant que nous commencions à rédiger le plan de mise en œuvre. »

Attendez la réponse de l’utilisateur. S’il demande des modifications, effectuez-les et relancez le cycle de révision des spécifications. Ne poursuivez qu’une fois que l’utilisateur a donné son accord.

Mise en œuvre :

Appelez la compétence « writing-plans » pour créer un plan de mise en œuvre détaillé
N’invoquez AUCUNE autre compétence. « writing-plans » est l’étape suivante.

Principes clés

Une question à la fois – Ne submergez pas l’utilisateur de questions
Privilégiez les questions à choix multiples: elles sont plus faciles à répondre que les questions ouvertes lorsque c'est possible
Appliquez leprincipe YAGNI sans concession: supprimez les fonctionnalités superflues de toutes les conceptions
Explorer les alternatives: toujours proposer 2 à 3 approches avant de se décider
Validation progressive: présentez la conception et obtenez l'accord avant de passer à l'étape suivante
Faites preuve de souplesse: revenez en arrière et clarifiez les points qui ne semblent pas clairs

Outil d'accompagnement visuel

Un outil complémentaire basé sur un navigateur permettant de présenter des maquettes, des schémas et des options visuelles pendant l’ brainstorming. Disponible en tant qu’outil — et non en tant que mode de fonctionnement. Accepter l’utilisation de cet outil signifie qu’il est disponible pour les questions qui gagnent à être traitées visuellement ; cela ne signifie PAS que chaque question passe par le navigateur.

Proposer l’outil d’accompagnement (au moment opportun) : ne le proposez PAS d’emblée. Attendez qu’une question puisse véritablement être clarifiée par une illustration plutôt que par des mots — une véritable question portant sur une maquette, une mise en page ou un diagramme, et non pas simplement un sujet lié à l’interface utilisateur. La première fois que cela se produit, proposez-le alors, sous la forme d’un message distinct :

« La partie suivante serait peut-être plus facile si je vous la montrais — je peux créer des maquettes, des schémas et des comparaisons dans un onglet du navigateur au fur et à mesure. C’est encore tout nouveau et cela peut consommer beaucoup de jetons. Voulez-vous que je le fasse ? Je vais l’ouvrir pour vous. »

Cette proposition DOIT constituer un message à part entière. Uniquement la proposition — pas de question de clarification, de résumé ou d’autre contenu. Attendez la réponse de l’utilisateur. S’il accepte, lancez le serveur avec l’option --open afin que son navigateur s’ouvre automatiquement sur le premier écran. S’il refuse, continuez en mode texte uniquement et ne refaites pas cette proposition à moins qu’il n’en fasse la demande.

Décision au cas par cas : même après l’acceptation de l’utilisateur, décidez POUR CHAQUE QUESTION s’il faut utiliser le navigateur ou le terminal. Le critère : l’utilisateur comprendrait-il mieux en voyant plutôt qu’en lisant ?

Utilisez le navigateur pour les contenus visuels : maquettes, wireframes, comparaisons de mises en page, schémas d’architecture, comparaisons visuelles côte à côte
Utilisez le terminal pour les contenus textuels : questions sur les exigences, choix conceptuels, listes de compromis, options textuelles A/B/C/D, décisions relatives à la portée

Une question portant sur un sujet lié à l’interface utilisateur n’est pas automatiquement une question visuelle. « Que signifie la personnalité dans ce contexte ? » est une question conceptuelle — utilisez le terminal. « Quelle mise en page d’assistant fonctionne le mieux ? » est une question visuelle — utilisez le navigateur.

S’ils acceptent le guide d’accompagnement, lisez le guide détaillé avant de continuer : skills/brainstorming/visual-companion.md

Voir sur GitHub

---
name: brainstorming
description: Guides collaborative dialogue to turn ideas into fully formed designs and specs before any implementation begins.
---

# Brainstorming Ideas Into Designs

Help turn ideas into fully formed designs and specs through natural collaborative dialogue.

Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.

<HARD-GATE>
Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
</HARD-GATE>

## Anti-Pattern: "This Is Too Simple To Need A Design"

Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.

## Checklist

You MUST create a task for each of these items and complete them in order:

1. **Explore project context** — check files, docs, recent commits
2. **Offer the visual companion just-in-time** — NOT upfront. The first time a question would genuinely be clearer shown than described, offer it then (its own message); on approval its browser tab opens for you. If no visual question ever arises, never offer it. See the Visual Companion section below.
3. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
4. **Propose 2-3 approaches** — with trade-offs and your recommendation
5. **Present design** — in sections scaled to their complexity, get user approval after each section
6. **Write design doc** — save to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md` and commit
7. **Spec self-review** — quick inline check for placeholders, contradictions, ambiguity, scope (see below)
8. **User reviews written spec** — ask user to review the spec file before proceeding
9. **Transition to implementation** — invoke writing-plans skill to create implementation plan

## Process Flow

```dot
digraph brainstorming {
    "Explore project context" [shape=box];
    "Ask clarifying questions" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Present design sections" [shape=box];
    "User approves design?" [shape=diamond];
    "Write design doc" [shape=box];
    "Spec self-review\n(fix inline)" [shape=box];
    "User reviews spec?" [shape=diamond];
    "Invoke writing-plans skill" [shape=doublecircle];

    "Explore project context" -> "Ask clarifying questions";
    "Ask clarifying questions" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Present design sections";
    "Present design sections" -> "User approves design?";
    "User approves design?" -> "Present design sections" [label="no, revise"];
    "User approves design?" -> "Write design doc" [label="yes"];
    "Write design doc" -> "Spec self-review\n(fix inline)";
    "Spec self-review\n(fix inline)" -> "User reviews spec?";
    "User reviews spec?" -> "Write design doc" [label="changes requested"];
    "User reviews spec?" -> "Invoke writing-plans skill" [label="approved"];
}
```

**The terminal state is invoking writing-plans.** Do NOT invoke frontend-design, mcp-builder, or any other implementation skill. The ONLY skill you invoke after brainstorming is writing-plans.

## The Process

**Understanding the idea:**

- Check out the current project state first (files, docs, recent commits)
- Before asking detailed questions, assess scope: if the request describes multiple independent subsystems (e.g., "build a platform with chat, file storage, billing, and analytics"), flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first.
- If the project is too large for a single spec, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then brainstorm the first sub-project through the normal design flow. Each sub-project gets its own spec → plan → implementation cycle.
- For appropriately-scoped projects, ask questions one at a time to refine the idea
- Prefer multiple choice questions when possible, but open-ended is fine too
- Only one question per message - if a topic needs more exploration, break it into multiple questions
- Focus on understanding: purpose, constraints, success criteria

**Exploring approaches:**

- Propose 2-3 different approaches with trade-offs
- Present options conversationally with your recommendation and reasoning
- Lead with your recommended option and explain why

**Presenting the design:**

- Once you believe you understand what you're building, present the design
- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
- Ask after each section whether it looks right so far
- Cover: architecture, components, data flow, error handling, testing
- Be ready to go back and clarify if something doesn't make sense

**Design for isolation and clarity:**

- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.

**Working in existing codebases:**

- Explore the current structure before proposing changes. Follow existing patterns.
- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
- Don't propose unrelated refactoring. Stay focused on what serves the current goal.

## After the Design

**Documentation:**

- Write the validated design (spec) to `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`
  - (User preferences for spec location override this default)
- Use elements-of-style:writing-clearly-and-concisely skill if available
- Commit the design document to git

**Spec Self-Review:**
After writing the spec document, look at it with fresh eyes:

1. **Placeholder scan:** Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
2. **Internal consistency:** Do any sections contradict each other? Does the architecture match the feature descriptions?
3. **Scope check:** Is this focused enough for a single implementation plan, or does it need decomposition?
4. **Ambiguity check:** Could any requirement be interpreted two different ways? If so, pick one and make it explicit.

Fix any issues inline. No need to re-review — just fix and move on.

**User Review Gate:**
After the spec review loop passes, ask the user to review the written spec before proceeding:

> "Spec written and committed to `<path>`. Please review it and let me know if you want to make any changes before we start writing out the implementation plan."

Wait for the user's response. If they request changes, make them and re-run the spec review loop. Only proceed once the user approves.

**Implementation:**

- Invoke the writing-plans skill to create a detailed implementation plan
- Do NOT invoke any other skill. writing-plans is the next step.

## Key Principles

- **One question at a time** - Don't overwhelm with multiple questions
- **Multiple choice preferred** - Easier to answer than open-ended when possible
- **YAGNI ruthlessly** - Remove unnecessary features from all designs
- **Explore alternatives** - Always propose 2-3 approaches before settling
- **Incremental validation** - Present design, get approval before moving on
- **Be flexible** - Go back and clarify when something doesn't make sense

## Visual Companion

A browser-based companion for showing mockups, diagrams, and visual options during brainstorming. Available as a tool — not a mode. Accepting the companion means it's available for questions that benefit from visual treatment; it does NOT mean every question goes through the browser.

**Offering the companion (just-in-time):** Do NOT offer it upfront. Wait until a question would genuinely be clearer shown than told — a real mockup / layout / diagram question, not merely a UI *topic*. The first time that happens, offer it then, as its own message:
> "This next part might be easier if I show you — I can put together mockups, diagrams, and comparisons in a browser tab as we go. It's still new and can be token-intensive. Want me to? I'll open it for you."

**This offer MUST be its own message.** Only the offer — no clarifying question, summary, or other content. Wait for the user's response. If they accept, start the server with `--open` so their browser opens to the first screen automatically. If they decline, continue text-only and don't offer again unless they raise it.

**Per-question decision:** Even after the user accepts, decide FOR EACH QUESTION whether to use the browser or the terminal. The test: **would the user understand this better by seeing it than reading it?**

- **Use the browser** for content that IS visual — mockups, wireframes, layout comparisons, architecture diagrams, side-by-side visual designs
- **Use the terminal** for content that is text — requirements questions, conceptual choices, tradeoff lists, A/B/C/D text options, scope decisions

A question about a UI topic is not automatically a visual question. "What does personality mean in this context?" is a conceptual question — use the terminal. "Which wizard layout works better?" is a visual question — use the browser.

If they agree to the companion, read the detailed guide before proceeding:
`skills/brainstorming/visual-companion.md`