Brainstorming socratique AVANT de coder - clarifier le problème par questions ciblées plutôt que sauter à la solution. Use when requirements are ambiguous or before starting a non-trivial feature.
Installs into .claude/skills of the current project.
Are you the author of Socratic Brainstorm?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/thebeardedbearsas-socratic-brainstorm)
---
name: socratic-brainstorm
description: Brainstorming socratique AVANT de coder - clarifier le problème par questions ciblées plutôt que sauter à la solution. Use when requirements are ambiguous or before starting a non-trivial feature.
context: fork
---
# Socratic Brainstorm — Clarifier avant de coder
Skill inspiré de [obra/superpowers](https://github.com/obra/superpowers). **Objectif :** forcer une phase de questions ciblées avant toute implémentation, pour éviter de coder la mauvaise chose très vite.
**Règle d'or :** une question coûte 30 secondes, un faux développement coûte 3 jours.
## Méthode socratique : 5 familles de questions
À poser **avant** de toucher au code. Pas toutes à chaque fois — choisir les plus pertinentes selon le contexte.
### 1. Questions sur le PROBLÈME
- Quel est le **vrai** problème à résoudre ? (pas la solution supposée)
- Pour qui ? Quel persona / rôle utilisateur ?
- Quel est le coût de **ne rien faire** ?
- Comment mesurera-t-on le succès ? (KPI, métrique)
- Y a-t-il une solution plus simple qui résout 80% du besoin ?
### 2. Questions sur les CONTRAINTES
- Contraintes **métier** : règles légales, compliance, SLA ?
- Contraintes **techniques** : stack imposée, dépendances, legacy ?
- Contraintes **temporelles** : deadline, dépendances externes ?
- Contraintes **ressources** : budget infra, RH, maintenance long terme ?
- Que ne faut-il **surtout pas** casser ?
### 3. Questions sur les ALTERNATIVES
- Quelles sont les 3 approches possibles ? (minimum)
- Pourquoi celle-ci plutôt qu'une autre ?
- Qu'a-t-on déjà essayé / envisagé ?
- Existe-t-il une solution off-the-shelf (lib, SaaS) ?
- Peut-on ne rien coder (config, manuel, process) ?
### 4. Questions sur les HYPOTHÈSES
- Qu'est-ce qu'on **suppose** sans avoir vérifié ?
- Quel est le volume / trafic attendu ?
- Quel est le pattern d'usage réel (95% cas / 5% edge cases) ?
- Quels acteurs externes impliqués ? (API tierces, équipes, utilisateurs)
- Que se passe-t-il si cette hypothèse est fausse ?
### 5. Questions sur les CONSÉQUENCES
- Qu'est-ce qui change pour l'utilisateur final ?
- Impact sur les autres features / modules ?
- Coûts d'exploitation (infra, monitoring, support) ?
- Comment rollback si ça tourne mal ?
- Comment évolue cette solution dans 1 an, 3 ans ?
## Output attendu
Après la phase brainstorm, produire **une page** (max) avec :
1. **Problème reformulé** en 1-2 phrases
2. **Contraintes** principales (5 bullets max)
3. **Option retenue** + **2 alternatives** rejetées avec raison
4. **Hypothèses clés** à valider en début d'implémentation
5. **Risques identifiés** + mitigations
## Règles d'or
### NE PAS sauter cette phase si :
- La demande initiale contient le mot "peut-être", "probablement", "je pense"
- Le demandeur n'est pas un utilisateur final
- Multiple solutions semblent possibles à première vue
- La feature touche du code legacy ou un domaine complexe
### SAUTER cette phase si :
- Bug obvious avec un seul fix possible
- Typo / formatage / doc
- Tâche < 10 min avec périmètre trivial
## Anti-patterns
| Anti-pattern | Solution |
|--------------|----------|
| Brainstorm infini sans décision | Timebox 30 min max |
| Questions rhétoriques (réponse évidente) | Questions **ouvertes** et utiles |
| Répondre soi-même sans demander | Vraiment poser les questions au demandeur |
| Skip brainstorm "parce que c'est urgent" | L'urgence coûte 10x le brainstorm évité |
| Noter les réponses dans sa tête | Écrire = visible, revisitable, versionable |
## Intégration Claude Craft
- **`/workflow:analyze`** — phase d'analyse BMAD commence par ce skill
- **`/workflow:plan`** — PRD doit répondre aux 5 familles de questions
- **Agent `@product-owner`** — peut conduire le brainstorm avec le demandeur
- **Skill `atomic-tasks`** — l'output du brainstorm se découpe en tâches atomiques
- **Skill `architect`** — vient APRÈS le brainstorm pour les features architecturales
## Variante rapide : "5 Whys"
Pour bugs ou causes racines, utiliser les **5 Whys** de Toyota :
```
Bug: "Le paiement échoue"
Why 1: Pourquoi ? → L'API retourne 500
Why 2: Pourquoi ? → Timeout DB
Why 3: Pourquoi ? → Requête sans index
Why 4: Pourquoi ? → Colonne ajoutée sans migration d'index
Why 5: Pourquoi ? → Pas de checklist PR pour les migrations
```
**Cause racine :** absence de checklist, pas le 500.
## Ressources
- [obra/superpowers](https://github.com/obra/superpowers)
- [Socratic Method - Wikipedia](https://en.wikipedia.org/wiki/Socratic_method)
- [5 Whys - Toyota](https://en.wikipedia.org/wiki/Five_whys)
- Skill `atomic-tasks`, `architect`
---
**Date de dernière mise à jour :** 2026-04-15
**Version :** 1.0.0