brainstorming

Vue d’ensemble du skill brainstorming

À quoi sert le skill brainstorming

Le skill brainstorming propose un workflow structuré, en amont de l’implémentation, pour transformer une idée encore floue en design validé avant d’écrire la moindre ligne de code. Sa fonction principale n’est pas simplement de « générer des idées » de manière abstraite ; il sert surtout à limiter les allers-retours et le rework en obligeant à expliciter d’abord le périmètre, les hypothèses, les exigences et les choix de conception.

Qui devrait installer ce skill brainstorming

Ce skill brainstorming convient particulièrement aux personnes qui passent trop vite de « on devrait construire X » à l’implémentation. Il est particulièrement utile pour :

• la planification de fonctionnalités
• la conception de composants
• les changements de comportement
• les propositions d’outils internes
• le brainstorming pour Requirements Planning

Si vous disposez déjà d’un processus de spécification rigoureux, ce skill peut malgré tout servir de couche d’entrée légère avant ce processus.

Ce qui le distingue d’un prompt classique

Le vrai point différenciant, c’est la règle stricte inscrite dans SKILL.md : l’agent ne doit ni implémenter, ni scaffold, ni écrire du code tant qu’il n’a pas présenté un design et obtenu une validation. Cela paraît simple, mais en pratique ce garde-fou change nettement le comportement par rapport à un prompt ordinaire du type « aide-moi à construire ça », où les assistants ont souvent tendance à sauter directement à la solution.

Ce que les utilisateurs veulent vraiment savoir avant d’installer

Avant l’installation, la plupart des utilisateurs cherchent surtout à trancher rapidement sur trois points :

1. Est-ce que ça va me ralentir ?
2. Est-ce que les questions posées seront utiles plutôt que génériques ?
3. Est-ce que ça peut aider sur des discussions de design visuel ?

La réponse est la suivante : oui, ce skill ajoute volontairement un peu de processus, mais cette surcharge reste faible quand l’idée de départ est simple. Le skill défend explicitement l’idée que même un travail « simple » mérite un court passage par le design, car c’est précisément là que des hypothèses cachées peuvent provoquer des erreurs coûteuses.

Comment utiliser le skill brainstorming

Installation et configuration du skill brainstorming

Pour ajouter le skill depuis le dépôt, utilisez :
npx skills add https://github.com/obra/superpowers --skill brainstorming

Après l’installation, ouvrez d’abord ces fichiers :

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

Si vous prévoyez une exploration visuelle, inspectez aussi :

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

Le workflow central attendu par le skill brainstorming

Le mode d’usage de brainstorming est volontairement cadré :

1. explorer le contexte du projet
2. proposer éventuellement le companion visuel
3. poser des questions de clarification une par une
4. synthétiser le design
5. obtenir une validation explicite
6. seulement ensuite passer à la planification ou à l’implémentation

Si votre agent passe directement de l’idée au code, alors il ne suit pas vraiment ce skill.

Quels éléments fournir pour un meilleur usage de brainstorming

Le skill fonctionne beaucoup mieux si vous fournissez autre chose qu’un simple titre de fonctionnalité. Un bon point de départ inclut généralement :

• le problème à résoudre
• l’utilisateur concerné
• le contexte du système actuel ou du repo
• les contraintes
• ce que signifie « terminé »
• les non-objectifs déjà connus

Un input faible :

Add notifications.

Un input plus solide :

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

Cette seconde version donne au skill brainstorming suffisamment de structure pour poser des questions de suivi plus précises et plus utiles.

Comment transformer une idée floue en premier prompt solide avec le skill brainstorming

Voici un modèle de prompt pratique pour brainstorming :

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

Ce format colle au flux prévu par le skill et réduit le risque d’obtenir une série de questions génériques.

Comment les questions de clarification doivent fonctionner

Il y a ici un comportement subtil mais essentiel : le skill attend des questions une par une, et non un énorme questionnaire d’exploration envoyé d’un seul coup. C’est important, car chaque réponse peut modifier la question suivante. Si votre agent déverse 15 questions d’un bloc, vous perdez tout le raffinement interactif que ce guide brainstorming est justement censé instaurer.

Quand utiliser le companion visuel

Le dépôt inclut un companion visuel accessible dans le navigateur. Utilisez-le quand l’utilisateur comprendra mieux les options en les voyant :

• wireframes
• comparaisons de layouts
• parcours UI
• diagrammes d’architecture
• visualisations d’états ou de relations

Ne l’utilisez pas simplement parce que le sujet touche à l’UI. Une question conceptuelle comme « should this be a wizard or a modal? » peut très bien rester textuelle. En revanche, une question comme « which of these two wizard layouts is clearer? » correspond très bien au parcours visuel.

Comment le companion visuel est réellement servi

L’outil visuel n’est pas qu’un morceau de documentation ; le dépôt contient bien des scripts pour lancer une session locale :

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh lance un serveur local sur un port élevé aléatoire et peut stocker les fichiers de session soit dans /tmp, soit dans un répertoire projet comme .superpowers/brainstorm/. C’est utile si vous souhaitez conserver les mockups d’une session à l’autre.

Notes pratiques d’environnement avant de vous appuyer sur les visuels

Le workflow visuel suppose un environnement accessible depuis un navigateur. Si vous travaillez dans un conteneur distant, une VM ou via SSH, faites particulièrement attention à :

• --host
• --url-host
• la persistance du répertoire de session

Pour un usage purement local, les réglages par défaut sont simples. En environnement partagé ou distant, mieux vaut anticiper les détails réseau avant de structurer tout votre workflow autour du retour visuel.

Meilleur parcours de lecture des fichiers pour une adoption rapide

Si vous cherchez le chemin le plus court vers un usage réellement efficace, lisez dans cet ordre :

1. SKILL.md pour le contrat de comportement
2. visual-companion.md pour comprendre quand le support navigateur apporte un vrai plus
3. spec-document-reviewer-prompt.md pour voir à quoi ressemble un livrable « suffisamment bon pour être implémenté »
4. scripts/start-server.sh si vous avez besoin du volet visuel

Vous obtenez ainsi d’abord la logique de décision, puis l’outillage optionnel.

À quoi doit ressembler un bon résultat avec le skill brainstorming

Une session brainstorming réussie doit se terminer par un design suffisamment concret pour être relu et validé, incluant :

• l’objectif et l’utilisateur
• les frontières du périmètre
• les décisions clés
• les risques ou hypothèses encore ouverts
• assez de précision pour planifier l’implémentation

Si le résultat n’est qu’une liste d’idées vagues, c’est que la session s’est arrêtée trop tôt.

Comment utiliser brainstorming pour Requirements Planning

Pour le brainstorming pour Requirements Planning, utilisez le skill comme étape pré-spécification :

1. clarifier le problème et les contraintes
2. esquisser la forme du design ou des requirements
3. obtenir une validation
4. rédiger la spec
5. exécuter si besoin le template de prompt du reviewer de spec

C’est l’un des usages les plus solides du skill, car il permet de repérer la dérive de périmètre et les ambiguïtés avant que la planification ne se fige.

FAQ sur le skill brainstorming

Le skill brainstorming est-il réservé aux gros projets ?

Non. Le skill rejette explicitement l’idée selon laquelle un travail « petit » pourrait se passer de design. Pour un changement minime, le design attendu peut être très court, mais l’étape de design reste importante. La valeur est souvent maximale sur des modifications supposées simples, justement parce que les hypothèses y sont rarement testées.

Est-ce meilleur que des prompts de brainstorming classiques ?

En général, oui, si votre objectif réel est d’obtenir une clarté exploitable pour l’exécution plutôt qu’un grand volume d’idées. Un prompt de brainstorming classique peut générer beaucoup d’options. Ce skill brainstorming est plus adapté quand vous avez besoin de convergence : comprendre le contexte, resserrer les choix et produire un design validé.

Le skill brainstorming est-il adapté aux débutants ?

Oui, surtout pour les personnes qui construisent seules et qui n’ont pas encore pris l’habitude de planifier. La structure compense une erreur fréquente chez les débutants : implémenter la première idée plausible sans avoir clarifié d’abord les exigences ni les arbitrages.

Dans quels cas brainstorming est-il mal adapté ?

Mieux vaut l’éviter ou le raccourcir quand :

• la tâche est purement mécanique et déjà entièrement spécifiée
• vous ne prenez pas de décision de design ou de comportement
• l’utilisateur a déjà validé une spec détaillée et attend seulement l’exécution

Même dans ces cas, vérifiez que la règle stricte ne perturbe pas votre workflow. Ce skill est volontairement exigeant.

Est-ce que ce skill génère du code ?

Non, et c’est intentionnel. Le skill brainstorming est censé s’arrêter avant l’implémentation tant qu’aucune validation n’a été donnée. Si vous voulez de la génération de code, utilisez d’abord ce skill, puis passez à un skill de planification ou d’implémentation une fois le design approuvé.

Faut-il absolument le companion visuel pour en tirer de la valeur ?

Non. Le parcours navigateur est optionnel. Un usage textuel de brainstorming apporte déjà l’essentiel de la valeur pour les discussions sur les requirements, le périmètre et les compromis techniques. Les outils visuels deviennent surtout importants quand la décision elle-même est visuelle.

Comment améliorer le skill brainstorming

Donner au skill brainstorming un contexte projet plus riche

Le moyen le plus rapide d’améliorer les résultats est d’ancrer la discussion dans le réel :

• les fichiers ou dossiers pertinents
• le comportement existant
• les changements récents
• les contraintes techniques connues
• les utilisateurs concernés

Le skill lui-même demande à l’agent d’explorer d’abord le contexte du projet. Aidez-le en indiquant précisément où ce contexte se trouve.

Énoncer tôt les contraintes et les non-objectifs

Beaucoup de sorties brainstorming faibles viennent de frontières mal définies. Dites clairement au skill ce qu’il doit préserver ou éviter :

• compatibilité descendante
• limites de performance
• exigences de conformité ou de sécurité
• contraintes de planning ou de staffing
• fonctionnalités explicitement hors périmètre

Vous obtiendrez ainsi des designs plus resserrés et plus utiles pour décider.

Demander un design, pas seulement des idées

Si vous voulez un résultat prêt à nourrir l’implémentation, dites-le explicitement. Demandez au skill brainstorming de se terminer par :

• un design proposé
• les hypothèses
• les questions non résolues
• un point de validation explicite

Cela évite de dériver vers une idéation sans fin et oriente la session vers un artefact réellement exploitable.

Utiliser des prompts plus précis pour le brainstorming visuel

Pour le travail visuel, ne dites pas simplement « show mockups ». Précisez ce que le visuel doit comparer :

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

Ce type de prompt aide le companion visuel à produire un résultat orienté décision plutôt que des écrans purement décoratifs.

Surveiller le principal mode d’échec : partir trop tôt dans la solution

Le plus gros risque consiste à sauter vers des détails d’implémentation avant d’avoir réellement compris le problème. Si cela arrive, recadrez la session :

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

Cela permet de réaligner le guide brainstorming sur sa finalité centrale.

Améliorer le premier résultat avec une passe de review ciblée

Après le design initial, demandez une révision ciblée plutôt que de recommencer depuis zéro :

• qu’est-ce qui est ambigu ?
• qu’est-ce qui est surconçu ?
• qu’est-ce qui bloquerait la planification de l’implémentation ?
• qu’est-ce qui manque pour obtenir une validation ?

Le fichier spec-document-reviewer-prompt.md du dépôt est particulièrement utile ici, car il calibre la review sur de vrais bloqueurs de planification, et non sur des retouches cosmétiques.

Garder l’artefact brainstorming compact mais complet pour la décision

Une erreur fréquente consiste à gonfler le design avec des détails inutiles. Un meilleur brainstorming n’est pas un brainstorming plus long. Pour un travail simple, quelques paragraphes resserrés couvrant l’objectif, le périmètre, les contraintes, l’approche et la validation peuvent suffire. Le bon critère n’est pas la longueur du document, mais le fait que l’étape suivante puisse avancer avec moins d’incertitude.

Associer brainstorming à une étape de review de spec

Si vous adoptez ce skill sérieusement, combinez-le avec une revue du design ou de la spec produite. Le template de review inclus vérifie notamment :

• les placeholders
• les contradictions
• les requirements ambiguës
• un périmètre trop large
• une complexité non demandée

C’est ce qui rend le skill brainstorming réellement utile dans un workflow de delivery concret, et pas seulement dans une conversation.