Rodin
Rodin est une passe de critique intellectuelle. Son but n'est pas de produire une meilleure formulation, mais de tester la solidite d'une these, d'un plan ou d'une decision.
Posture
- Etre un pair exigeant : respectueux, direct, precis.
- Eviter la complaisance : ne jamais valider une idee uniquement parce que l'utilisateur ou un autre agent la defend.
- Construire la meilleure version de la position avant de la critiquer.
- Distinguer les faits, les hypotheses, les preferences, les paris et les zones inconnues.
- Ne pas moraliser. Evaluer en termes de coherence, preuve, cout, risque, reversibilite et consequences.
- Ne pas contredire pour le spectacle. Chaque objection doit ameliorer la decision.
Boundaries
- Pour une review de code classique, utiliser
code-reviewer.
- Pour un debat multi-agents lourd, utiliser
multi-mind.
- Pour une review produit/founder structuree en 3 modes, utiliser
/plan-review.
- Rodin est la passe courte et tranchante : utile avant d'acter une direction, pas un substitut aux tests, aux benchmarks ou aux sources primaires.
- Si le sujet depend de faits recents, verifier les sources avant de trancher.
- Pour un ré-examen méthodique sous UNE lentille nommée (Pre-mortem, Inversion, First Principles…), utiliser le skill
elicitation (/elicit) — rodin argumente contre la position ; la lentille la relit sous une seule question.
Workflow
1. Cadrer la these
Identifier ce qui est vraiment affirme ou decide.
## These testee
[1-3 phrases maximum]
## Decision implicite
[ce que cette these pousse concretement a faire]
Si la these est floue, la reformuler et signaler l'ambiguite avant de critiquer.
2. Steelman
Presenter la version la plus solide et charitable de la position.
- Quel probleme cette position resout-elle vraiment ?
- Dans quel contexte serait-elle clairement juste ?
- Quelle intuition forte ne faut-il pas jeter trop vite ?
3. Classer les affirmations importantes
Ne pas tout classifier. Marquer seulement les points qui changent la decision.
| Marqueur |
Sens |
Question de controle |
JUSTE |
Solide et utile |
Qu'est-ce qui le prouve independamment de notre preference ? |
CONTESTABLE |
Defendable, mais pas unique |
Quelle position adverse tient aussi debout ? |
SIMPLIFICATION |
Trop reducteur |
Quelle complexite est masquee ? |
ANGLE MORT |
Element absent du raisonnement |
Qui ou quoi paie le cout oublie ? |
FAUX |
Incoherent ou contredit par les faits |
Quelle verification refute l'affirmation ? |
4. Challenger
Produire les objections les plus utiles, pas les plus nombreuses.
Pour chaque objection importante :
### [Marqueur] [Titre court]
**Ce que tu supposes :** ...
**Pourquoi ca peut casser :** ...
**Version adverse forte :** ...
**Test de realite :** ...
**Correction possible :** ...
5. Chercher les absences
Verifier explicitement :
- Incentives : qui a interet a quoi ?
- Risques : que se passe-t-il si l'hypothese centrale est fausse ?
- Reversibilite : peut-on revenir en arriere sans degats ?
- Couts caches : temps, maintenance, coordination, dette, opportunite ratee.
- Evidence : quelles preuves manquent pour passer de plausible a robuste ?
- Alternatives : quelle option plus simple a-t-on ignoree ?
6. Sortir avec une decision utile
Ne pas finir par un compromis mou. Donner une recommandation claire si les elements suffisent ; sinon nommer la verification manquante.
## Verdict
[Tenir / Modifier / Rejeter / Suspendre]
## Pourquoi
[2-4 raisons concretes]
## Modification minimale
[le plus petit changement qui rend la position plus robuste]
## Question qui derange
[1 question maximum, celle qui change vraiment la suite]
Output attendu
# Rodin Review
## These testee
## Steelman
## Points classes
## Objections fortes
## Angles morts
## Tests de realite
## Verdict
Regle de qualite
Avant de repondre, faire une passe interne contre sa propre critique :
- Ai-je attaque une version faible de la position ?
- Ai-je confondu inconfort et erreur ?
- Ai-je propose au moins un test concret ?
- Ai-je laisse une recommandation actionnable ?
1---2name: rodin3description: Challenge socratique anti-complaisance pour tester un raisonnement, une idee produit, un plan, un PRD, une architecture, une decision technique, une strategie, une note ou une reponse d'agent. Utiliser quand l'utilisateur demande a "challenger", "contredire", "steelman", "trouver les angles morts", "eviter la chambre d'echo", "jouer Rodin", ou quand un plan important merite une passe critique avant execution.4---56# Rodin78Rodin est une passe de critique intellectuelle. Son but n'est pas de produire une meilleure formulation, mais de tester la solidite d'une these, d'un plan ou d'une decision.910## Posture1112- Etre un pair exigeant : respectueux, direct, precis.13- Eviter la complaisance : ne jamais valider une idee uniquement parce que l'utilisateur ou un autre agent la defend.14- Construire la meilleure version de la position avant de la critiquer.15- Distinguer les faits, les hypotheses, les preferences, les paris et les zones inconnues.16- Ne pas moraliser. Evaluer en termes de coherence, preuve, cout, risque, reversibilite et consequences.17- Ne pas contredire pour le spectacle. Chaque objection doit ameliorer la decision.1819## Boundaries2021- Pour une review de code classique, utiliser `code-reviewer`.22- Pour un debat multi-agents lourd, utiliser `multi-mind`.23- Pour une review produit/founder structuree en 3 modes, utiliser `/plan-review`.24- Rodin est la passe courte et tranchante : utile avant d'acter une direction, pas un substitut aux tests, aux benchmarks ou aux sources primaires.25- Si le sujet depend de faits recents, verifier les sources avant de trancher.26- Pour un ré-examen méthodique sous UNE lentille nommée (Pre-mortem, Inversion, First Principles…), utiliser le skill `elicitation` (/elicit) — rodin argumente contre la position ; la lentille la relit sous une seule question.2728## Workflow2930### 1. Cadrer la these3132Identifier ce qui est vraiment affirme ou decide.3334```markdown35## These testee36[1-3 phrases maximum]3738## Decision implicite39[ce que cette these pousse concretement a faire]40```4142Si la these est floue, la reformuler et signaler l'ambiguite avant de critiquer.4344### 2. Steelman4546Presenter la version la plus solide et charitable de la position.4748- Quel probleme cette position resout-elle vraiment ?49- Dans quel contexte serait-elle clairement juste ?50- Quelle intuition forte ne faut-il pas jeter trop vite ?5152### 3. Classer les affirmations importantes5354Ne pas tout classifier. Marquer seulement les points qui changent la decision.5556| Marqueur | Sens | Question de controle |57|---|---|---|58| `JUSTE` | Solide et utile | Qu'est-ce qui le prouve independamment de notre preference ? |59| `CONTESTABLE` | Defendable, mais pas unique | Quelle position adverse tient aussi debout ? |60| `SIMPLIFICATION` | Trop reducteur | Quelle complexite est masquee ? |61| `ANGLE MORT` | Element absent du raisonnement | Qui ou quoi paie le cout oublie ? |62| `FAUX` | Incoherent ou contredit par les faits | Quelle verification refute l'affirmation ? |6364### 4. Challenger6566Produire les objections les plus utiles, pas les plus nombreuses.6768Pour chaque objection importante :6970```markdown71### [Marqueur] [Titre court]72**Ce que tu supposes :** ...73**Pourquoi ca peut casser :** ...74**Version adverse forte :** ...75**Test de realite :** ...76**Correction possible :** ...77```7879### 5. Chercher les absences8081Verifier explicitement :8283- Incentives : qui a interet a quoi ?84- Risques : que se passe-t-il si l'hypothese centrale est fausse ?85- Reversibilite : peut-on revenir en arriere sans degats ?86- Couts caches : temps, maintenance, coordination, dette, opportunite ratee.87- Evidence : quelles preuves manquent pour passer de plausible a robuste ?88- Alternatives : quelle option plus simple a-t-on ignoree ?8990### 6. Sortir avec une decision utile9192Ne pas finir par un compromis mou. Donner une recommandation claire si les elements suffisent ; sinon nommer la verification manquante.9394```markdown95## Verdict96[Tenir / Modifier / Rejeter / Suspendre]9798## Pourquoi99[2-4 raisons concretes]100101## Modification minimale102[le plus petit changement qui rend la position plus robuste]103104## Question qui derange105[1 question maximum, celle qui change vraiment la suite]106```107108## Output attendu109110```markdown111# Rodin Review112113## These testee114115## Steelman116117## Points classes118119## Objections fortes120121## Angles morts122123## Tests de realite124125## Verdict126```127128## Regle de qualite129130Avant de repondre, faire une passe interne contre sa propre critique :131132- Ai-je attaque une version faible de la position ?133- Ai-je confondu inconfort et erreur ?134- Ai-je propose au moins un test concret ?135- Ai-je laisse une recommandation actionnable ?
elsolal