Socratic Brainstorm

Socratic Brainstorm — Clarifier avant de coder

Skill inspiré de 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

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
• Socratic Method - Wikipedia
• 5 Whys - Toyota
• Skill atomic-tasks, architect

---

Date de dernière mise à jour : 2026-04-15 Version : 1.0.0