tderoussel/decision-council

Ejecuta una revisión estructurada con múltiples perspectivas sobre una decisión, en lugar de obtener una única respuesta complaciente. Actívala cuando el usuario diga 'ejecuta un consejo', 'dame perspectivas sobre esto', '¿debería hacer X?', 'pon a prueba esta decisión' o '¿es una buena idea?'.

¿Qué es decision-council?

El skill Decision Council transforma la forma en que los agentes de IA evalúan decisiones complejas, reemplazando el típico sesgo de coherencia con un proceso estructurado de múltiples perspectivas. Diseñado para plataformas como Claude Code, Cursor o Codex, este skill evita que un agente único genere argumentos fluidos pero parciales (ya sea a favor o en contra) y en su lugar organiza un consejo de agentes con lentes independientes (contra-rio, optimista, operador, cliente, contador) que emiten recomendaciones sin verse influenciados entre sí. Luego, una ronda de revisión ciega por pares elimina la atribución para que los evaluadores juzguen los argumentos por su solidez, no por la autoridad percibida de la persona. Finalmente, un 'presidente' consolida las perspectivas y revisiones en un veredicto estructurado con confianza, contraargumentos y un paso concreto. Es ideal para decisiones con costos reales (comprar vs. construir, lanzar vs. retener, cambios de precio) y evita consensos forzados, reportando honestamente divisiones cuando ocurren. El patrón, creditado a Ollie Leman y popularizado por Remy Gaskell, escala de 3 a 7 personas según la importancia y la irreversibilidad de la decisión.

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

Installed? Explore more Productividad y colaboración skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Consejo de decisión

El problema que resuelve

Preguntar a un agente "¿por qué es una buena idea?" y obtienes un caso bien argumentado a favor. Preguntar "¿por qué es una mala idea?" y obtienes un caso igualmente bien argumentado en contra. Ambos son fluidos, ninguno es un juicio. Un solo agente es un mal asesor porque optimiza para una respuesta coherente, no correcta.

Esto ejecuta varias perspectivas independientes, las hace revisar por agentes que no saben quién escribió qué, y produce un veredicto.

Cuándo ejecutarlo

Bifurcaciones reales con costos reales: construir vs. comprar, lanzar vs. mantener, cambios de precios, si una característica es prematura, en qué trabajar a continuación. No para preguntas con una respuesta conocida.

Pasos

1. Enuncia la decisión con precisión

Escíbela como una oración con una bifurcación real. Si no se puede enunciar así, la decisión aún no está lo suficientemente clara para revisarla — arréglalo primero.

Reúne lo que realmente se sabe: restricciones, lo que ya se ha intentado, qué es reversible y qué no.

2. Convocar al consejo — en paralelo, independiente

Cinco agentes, cada uno con una lente genuinamente diferente. No deben ver las respuestas de los demás.

PersonaTrabajo
El contraríoSupón que esto falla. ¿Qué lo mató?
El optimistaSupón que funciona. ¿Qué desbloqueó que está siendo subvalorado?
El operador¿Quién hace el trabajo, qué se rompe, cuál es el costo real en el tiempo del usuario?
El cliente¿A la persona que paga realmente le importa? ¿Lo notaría?
El contador¿Qué cuesta esto, qué retorna, cuál es el costo de oportunidad?

Cada uno devuelve: una recomendación, el razonamiento y el único hecho que cambiaría su dictamen.

Intercambia una persona cuando la decisión lo requiera — una lente regulatoria para una bifurcación de cumplimiento, una lente de seguridad para una arquitectónica. Mantén las lentes genuinamente distintas.

3. Revisión por pares, ciega

Elimina la atribución y mezcla. Entrega el conjunto anonimizado a nuevos revisores. Pregunta a cada uno: ¿qué argumento es el más fuerte, cuál es el más débil, y qué pasaron por alto todos?

El cegamiento importa — evita que la revisión se subordine a la persona que suena más autorizada.

4. El presidente

Un agente final lee las perspectivas y las revisiones y devuelve:

## Decisión: <la pregunta>

**Veredicto:** <la decisión, en una oración>

**Confianza:** <alta | media | baja> — <por qué>

**El razonamiento que prevaleció:** <2-3 oraciones>

**El caso más fuerte en contra:** <exponlo de manera justa, no hagas un hombre de paja>

**Lo que cambiaría esto:** <el hecho o evento específico que invierte la respuesta>

**Si procedemos:** <primer paso concreto>

5. Informa con honestidad

Si el consejo se dividió, dilo. Un consenso forzado es peor que un desacuerdo vivo — la mayoría de las personas preferirían ver la tensión real y tomar la decisión ellos mismos.

Nunca fabriques acuerdo para parecer decisivo.

Escalarlo

Cinco personas es el valor predeterminado. Tres para una decisión menor, siete para algo costoso o difícil de revertir. Más personas solo ayuda si las lentes son genuinamente diferentes — cinco ángulos distintos vencen a nueve superpuestos.

Crédito

El patrón de múltiples personas más revisión ciega más presidente proviene de Ollie Leman, a través del episodio de Open Residency de Remy Gaskell sobre sistemas operativos de agentes.

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 relacionados