Mode d’emploi
- Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
- Consultez le document original pour les outils, identifiants et environnements requis.
- Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/thebeardedbearsas/claude-craft --skill socratic-brainstormAvant de commencer
- L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
- Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Document Skill original
Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.
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 :
- Problème reformulé en 1-2 phrases
- Contraintes principales (5 bullets max)
- Option retenue + 2 alternatives rejetées avec raison
- Hypothèses clés à valider en début d'implémentation
- 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 migrationsCause 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
