tderoussel/decision-council

Exécutez un examen structuré d'une décision sous plusieurs angles, plutôt qu'une seule réponse consensuelle. Utilisez-le lorsque l'utilisateur dit "organise un conseil", "donne-moi des perspectives sur ceci", "devrais-je faire X", "mets cette décision à l'épreuve" ou "est-ce une bonne idée".

Qu'est-ce que decision-council ?

Le skill Decision Council transforme un agent AI unique en un processus décisionnel multi-perspectives robuste. Il résout un problème fondamental des agents uniques : ils optimisent pour une réponse cohérente plutôt que correcte, produisant des arguments éloquents pour ou contre sans véritable jugement. Ce skill orchestre cinq agents aux perspectives distinctes (le contestataire, l'optimiste, l'opérateur, le client et le comptable) qui analysent une décision en parallèle sans voir les réponses des autres. Ensuite, un examen par les pairs en aveugle élimine les biais d'autorité, et un agent président synthétise un verdict avec niveau de confiance, arguments pour et contre, premier pas concret et conditions qui changeraient la décision. Le rapport signale honnêtement les désaccords sans forcer un consensus. Ce skill est idéal pour les fourches réelles avec coûts réels (construire vs acheter, livrer vs retenir, modifications de prix, choix de fonctionnalités). Il est conçu pour tout agent compatible avec les skills (ex. Claude Code). Bien qu'aucun fichier de configuration supplémentaire ne soit requis, il utilise le markdown structuré pour guider le processus, et les rôles peuvent être adaptés selon le contexte (conformité, sécurité).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/tderoussel/agent-skills/tree/main/skills/decision-council

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

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

Documentation

Conseil de décision

Le problème que cela résout

Demandez à un agent "pourquoi est-ce une bonne idée ?" et vous obtenez un argumentaire bien construit pour le oui. Demandez "pourquoi est-ce une mauvaise idée ?" et vous obtenez un argumentaire tout aussi bien construit pour le non. Les deux sont éloquents, aucun n'est un jugement. Un agent unique est un mauvais conseiller car il optimise pour une réponse cohérente plutôt que correcte.

Ce skill exécute plusieurs perspectives indépendantes, les fait réviser par des agents qui ne savent pas qui a écrit quoi, et produit un seul verdict.

Quand l'utiliser

Des fourches réelles avec des coûts réels : construire vs acheter, livrer vs retenir, changements de prix, savoir si une fonctionnalité est prématurée, sur quoi travailler ensuite. Pas pour des questions dont la réponse est déjà connue.

Étapes

1. Énoncez la décision avec précision

Rédigez-la en une phrase contenant une véritable fourche. Si elle ne peut pas être formulée ainsi, la décision n'est pas assez claire pour être examinée — corrigez cela d'abord.

Rassemblez ce qui est réellement connu : contraintes, ce qui a déjà été essayé, ce qui est réversible et ce qui ne l'est pas.

2. Convoquez le conseil — en parallèle, indépendant

Cinq agents, chacun avec un prisme réellement différent. Ils ne doivent pas voir les réponses des autres.

PersonaRôle
Le contestataireSupposez que cela échoue. Qu'est-ce qui l'a tué ?
L'optimisteSupposez que cela fonctionne. Qu'est-ce que cela a débloqué qui est sous-estimé ?
L'opérateurQui fait le travail, qu'est-ce qui casse, quel est le coût réel en temps pour l'utilisateur ?
Le clientEst-ce que la personne qui paie s'en soucie vraiment ? Le remarquerait-elle ?
Le comptableCombien cela coûte-t-il, combien cela rapporte-t-il, quel est le coût d'opportunité ?

Chacun retourne : une recommandation, le raisonnement, et le seul fait qui ferait changer d'avis.

Échangez une persona lorsque la décision l'exige — un prisme réglementaire pour une fourche de conformité, un prisme de sécurité pour une fourche d'architecture. Gardez les prismes réellement distincts.

3. Examen par les pairs, en aveugle

Supprimez l'attribution et mélangez. Confiez l'ensemble anonymisé à de nouveaux réviseurs. Demandez à chacun : quel argument est le plus fort, lequel est le plus faible, et qu'est-ce qu'ils ont tous manqué ?

L'aveuglement est important — il empêche l'examen de se référer à la persona qui semble la plus autoritaire.

4. Le président

Un dernier agent lit les perspectives et les examens et retourne :

## Décision : <la question>

**Verdict :** <la décision, en une phrase>

**Niveau de confiance :** <élevé | moyen | faible> — <pourquoi>

**Le raisonnement qui l'a emporté :** <2-3 phrases>

**L'argument le plus fort contre :** <énoncez-le équitablement — ne le réduisez pas à un homme de paille>

**Ce qui changerait cela :** <le fait ou l'événement spécifique qui inverserait la réponse>

**Si nous avançons :** <première étape concrète>

5. Rapportez honnêtement

Si le conseil est divisé, dites qu'il est divisé. Un consensus forcé est pire qu'un désaccord vivant — la plupart des gens préfèrent voir la vraie tension et prendre la décision eux-mêmes.

Ne fabriquez jamais d'accord pour paraître décisif.

Passage à l'échelle

Cinq personas est la valeur par défaut. Trois pour une décision plus petite, sept pour quelque chose de coûteux ou difficile à annuler. Plus de personas n'aide que si les prismes sont réellement différents — cinq angles distincts battent neuf angles qui se chevauchent.

Crédit

Le modèle multi-persona-plus-examen-en-aveugle-plus-président vient d'Ollie Leman, par l'intermédiaire de l'épisode d'Open Residency de Remy Gaskell sur les systèmes d'exploitation d'agents.

Individual skills in this repo

This repo contains 8 individual skills — each has its own dedicated page.

tderoussel/codebase-audit

Runs a ranked, evidence-backed audit of a product, codebase, or subsystem, ending in a verify list that separates proven findings from inferred ones. Use when the user asks for an audit, a gap analysis, a deep read, a bug hunt, a readiness check, a re-audit, a state reconciliation, or asks what they are not seeing. Trigger phrases include "audit", "gap analysis", "what am I missing", "deep audit", "readiness", "bug hunt", "review the whole thing". Produces findings and a verify list; does not fix.

tderoussel/competitive-teardown

Researches a competing product against your own and produces a ranked build-or-ignore verdict, plus optional comparison-page copy. Use when the user names a competitor or asks how their product stacks up against one. Trigger phrases include "vs us", "competitor", "what does X have", "should we copy", "competitive gap", "teardown", "are we behind". Produces a ranked verdict with effort estimates and an explicit not-worth-copying list.

tderoussel/fleet-brief

Authors a workstream brief for dispatching multiple parallel build agents across one codebase, with per-lane file ownership, shared-ground warnings, and a derived DO-NOT list. Use whenever work is about to be split across concurrent agents, workers, lanes, or waves — even if the user does not say "write a brief". Trigger phrases include "fan out", "parallel agents", "orchestrate this", "split into lanes", "workstreams", "run these in parallel", "review-gated build". Produces the brief; does not dispatch.

tderoussel/inbox-triage

Triage an email inbox — sort what needs a reply, draft the replies, flag what needs a decision, and surface what can be ignored or unsubscribed. Use when the user says triage my inbox, do my email, what's in my inbox, or clean up my email.

tderoussel/overnight-build

Composes an autonomous unattended Claude Code build prompt that survives usage-limit resets via BUILD_LOG.md checkpointing, plus the launcher that restarts it. Use when the user asks for an overnight build, an autonomous build, a build to run while they sleep, an unattended or unsupervised session, or any long build they will not be monitoring. Trigger phrases include "overnight build", "run overnight", "build while I sleep", "autonomous build", "let it run", "unattended". Produces a single copyable prompt; does not run the build.

tderoussel/session-log

Write a durable record of a work session — what was built, root-caused, or shipped — into the project's notes. Use when the user says log this session, write a session log, record this, or when a substantial piece of work has just finished and needs to be handed off to a future session.

tderoussel/ship-gate

Verification gate for a Next.js-on-Vercel + Supabase + GitHub Actions stack, to run before claiming anything is shipped, deployed, live, merged, passing, or done. Use before saying a change is in production, before merging a PR, before reporting CI green, and before writing any status into a document — even if the user does not ask for verification. Trigger phrases include "is it live", "did it deploy", "ship it", "merge it", "is CI green", "confirm prod", "did that work". Encodes traps where the obvious check returns a false pass.

tderoussel/vault-doctor

Audits and repairs an Obsidian vault's structural health — broken [[wikilinks]], ambiguous duplicate filenames, missing or malformed frontmatter, stale status markers, and hub notes whose state sections have gone cold. Use when the user asks about vault health, broken links, vault cleanup, dead links, orphan notes, tag consistency, or says the vault feels messy or out of date. Trigger phrases include "vault health", "broken links", "clean up the vault", "audit the vault", "is the vault current". Read-only by default; every repair is proposed before it is made.

Skills associés