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.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add TheBeardedBearSAS/claude-craft --skill socratic-brainstorm --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Socratic Brainstorm?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thebeardedbearsas-socratic-brainstorm)More formats (shields.io, HTML) on the badges page.
---
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
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!