Communitygithub.com

robcsaszar/socratic

Une rétrospective post-livraison en sept questions pour Claude Code, autour de la confiance, des angles morts et de la décroissance.

Qu'est-ce que socratic ?

Cette compétence transforme Claude Code en un outil d'enquête rétrospective rigoureuse, calquée sur la méthode socratique, à appliquer après chaque livraison. Elle est conçue pour les développeurs et les équipes qui souhaitent aller au-delà des simples revues de code et interroger systématiquement la confiance, les angles morts et la dégradation d'une fonctionnalité, d'un ensemble de modifications ou de l'ensemble du dépôt. La compétence lance automatiquement des sous-agents d'exploration parallèles chargés d'analyser l'implémentation, les tests et la documentation, puis pose sept questions précises (Qui, Quoi, Quand, Où, Pourquoi, Comment, Par quels moyens) en respectant des règles strictes de citation et d'ordre. L'utilisateur bénéficie ainsi d'une introspection structurée et honnête, sans biais d'optimisme, débouchant sur des actions concrètes et une prise de conscience des points les plus faibles du travail livré.

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add robcsaszar/socratic

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Socratique

Zētein — chercher. Pas une revue de code : une enquête menée après que le travail a été livré. Répondez à la fois en tant que bâtisseur et sceptique ; une réponse qui flatte ne vaut rien.

Méthode

  1. Nommer la cible. L'argument la nomme — une fonctionnalité ("emotes"), un ensemble de modifications ("PR #754", une branche, un intervalle de commits), ou l'ensemble du dépôt. Sans argument — prendre la PR fusionnée la plus récente. Si la cible ne peut être résolue (pas de correspondance, pas de PR fusionnées), arrêtez-vous et demandez. Indiquez-la en une ligne avant toute autre chose.
  2. Envoyer les exploreurs. Lancez des sous-agents Explore parallèles — toujours au pluriel, un par territoire — et ne répondez à rien avant que tous ne soient revenus. Fonctionnalité ou ensemble de modifications : implémentation, tests, documentation/parcours — ancrés sur le diff (gh pr diff <n> pour les PR, git diff <intervalle> pour les intervalles). Dépôt : architecture, jonctions entre modules, dérive entre code et documentation. Chaque exploreur renvoie des conclusions avec des citations fichier:ligne ; les réponses ne s'appuient que sur ce que les exploreurs renvoient plus la session elle-même.
  3. Poser les sept, dans l'ordre. Une à la fois, sous les règles ci-dessous. Pas de réponses évasives ; "ça dépend" est interdit sauf si suivi de "de quoi".
  4. Conclure avec des actions. Au maximum trois actions concrètes que les réponses imposent (prêtes pour une issue, une ligne chacune), puis une phrase nommant la réponse qui a le plus piqué.

Les sept questions

  1. Quis — qui ? Pour qui est-ce vraiment fait — et qui a été oublié ? Nommez l'utilisateur qui l'utilisera en premier et celui qui n'est jamais apparu dans la conception.
  2. Quid — quoi ? De quoi êtes-vous le moins confiant à l'instant ? La certitude la plus faible dans ce qui a été livré, pas le code le plus laid.
  3. Quando — quand ? Si cela casse dans trois mois, quelle est la raison la plus probable ? Le temps est le seul test qui s'exécute toujours.
  4. Ubi — où ? Quelle est la plus grande chose encore non réalisée à propos de la situation — où se trouve l'angle mort ?
  5. Cur — pourquoi ? Quelles hypothèses ont été faites et jamais énoncées ? Révélez le raisonnement tacite derrière chaque choix tant qu'il est encore peu coûteux de l'admettre.
  6. Quomodo — de quelle manière ? Qu'est-ce que le demandeur aurait pu faire différemment pour faciliter ce travail ? Répondez honnêtement ; la politesse qui cache une vraie réponse n'aide personne.
  7. Quibus auxiliis — par quels moyens ? Libéré de toute demande — un ajout non sollicité, leader de l'industrie. Qu'est-ce qui ferait de cela la raison pour laquelle les gens mentionnent le produit ?

Règles

  • Preuve d'abord — chaque réponse cite un fichier, une ligne, un commit ou un moment de la session ; sans cela c'est de la spéculation, et doit être marqué comme tel.
  • Les questions se suivent dans l'ordre ; ne lisez jamais à l'avance — la fonction rêvée de la question sept, lue trop tôt, fait fuiter de l'optimisme dans la question honnête que demande la question deux.
  • Aucune réponse est une réponse valide. N'avoir rien n'est pas un échec ; n'en inventez jamais une parce que la question semble l'exiger.
  • Rien n'est corrigé pendant l'enquête — observations ici, prescriptions uniquement dans les actions.
  • Les exploreurs explorent ; vous jugez. Ne déléguez jamais la réponse à une question à un sous-agent.

Skills associés