tderoussel/conselho-de-decisão

Realiza uma revisão estruturada e multiperspectiva de uma decisão, em vez de obter uma única resposta agradável. Use quando o usuário disser: execute um conselho, obtenha perspectivas sobre isso, devo fazer X, teste de estresse essa decisão, ou isso é uma boa ideia.

O que é conselho-de-decisão?

O conselho de decisão é uma habilidade para agentes de IA que implementa um processo de revisão estruturado e multiperspectiva para decisões complexas. Ele resolve o problema fundamental de um agente único que tende a produzir uma resposta coerente, mas não necessariamente correta — respondendo 'sim' ou 'não' fluentemente, sem um verdadeiro julgamento. A habilidade funciona organizando um conselho de múltiplas personas independentes (como o contrário, o otimista, o operador, o cliente e o contador), cada uma analisando a decisão de um ângulo diferente, sem ver as respostas umas das outras. Em seguida, as perspectivas são anonimizadas e submetidas a uma revisão cega por revisores independentes, que identificam o argumento mais forte, o mais fraco e o que todos ignoraram. Finalmente, um 'presidente' sintetiza tudo em um veredito final com nível de confiança e um próximo passo concreto. A habilidade é indicada para decisões reais com custos reais — como comprar versus construir, lançar versus segurar, mudanças de preço — e não para perguntas com respostas conhecidas. É baseada no padrão multi-persona-mais-revisão-cega-mais-presidente de Ollie Leman e funciona com qualquer agente que suporte a definição de ferramentas ou habilidades.

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

Installed? Explore more Produtividade e Colaboração skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Conselho de Decisão

O problema que isso resolve

Pergunte a um agente "por que isso é uma boa ideia?" e você receberá um argumento bem fundamentado a favor. Pergunte "por que isso é uma má ideia?" e você receberá um argumento igualmente bem fundamentado contra. Ambos são fluentes, nenhum é um julgamento. Um agente único é um mau conselheiro porque otimiza para uma resposta coerente, não para uma resposta correta.

Isso executa várias perspectivas independentes, faz com que sejam revisadas por agentes que não sabem quem escreveu o quê, e produz um único veredito.

Quando executar

Bifurcações reais com custos reais: construir vs. comprar, lançar vs. segurar, mudanças de preço, se um recurso é prematuro, no que trabalhar a seguir. Não para perguntas com uma resposta conhecida.

Passos

1. Defina a decisão com precisão

Escreva-a como uma frase com uma bifurcação real. Se não puder ser formulada assim, a decisão não está clara o suficiente para ser revisada ainda — corrija isso primeiro.

Reúna o que realmente se sabe: restrições, o que já foi tentado, o que é reversível e o que não é.

2. Convoque o conselho — em paralelo, independente

Cinco agentes, cada um com uma lente genuinamente diferente. Eles não devem ver as respostas uns dos outros.

PersonaFunção
O contrárioSuponha que falhe. O que o matou?
O otimistaSuponha que funcione. O que ele desbloqueou que está sendo subvalorizado?
O operadorQuem faz o trabalho, o que quebra, qual é o custo real no tempo do usuário?
O clienteA pessoa que paga realmente se importa? Ela notaria?
O contadorQuanto isso custa, quanto retorna, qual é o custo de oportunidade?

Cada um retorna: uma recomendação, o raciocínio e o único fato que mudaria sua opinião.

Troque uma persona quando a decisão exigir — uma lente regulatória para uma bifurcação de conformidade, uma lente de segurança para uma de arquitetura. Mantenha as lentes genuinamente distintas.

3. Revisão por pares, cega

Remova a atribuição e embaralhe. Entregue o conjunto anonimizado a novos revisores. Peça a cada um: qual argumento é o mais forte, qual é o mais fraco e o que todos eles deixaram passar?

A anonimização é importante — impede que a revisão se curve à persona que soa mais autoritária.

4. O presidente

Um agente final lê as perspectivas e as revisões e retorna:

## Decisão: <a pergunta>

**Veredito:** <a decisão, em uma frase>

**Confiança:** <alta | média | baixa> — <por quê>

**O raciocínio que prevaleceu:** <2-3 frases>

**O argumento mais forte contra:** <apresente-o de forma justa — não o distorça>

**O que mudaria isso:** <o fato ou evento específico que inverte a resposta>

**Se prosseguirmos:** <primeiro passo concreto>

5. Relate honestamente

Se o conselho se dividiu, diga que se dividiu. Um consenso forçado é pior do que um desacordo real — a maioria das pessoas prefere ver a tensão real e tomar a decisão por si mesma.

Nunca fabrique concordância para parecer decisivo.

Escalonamento

Cinco personas é o padrão. Três para uma decisão menor, sete para algo caro ou difícil de reverter. Mais personas só ajudam se as lentes forem genuinamente diferentes — cinco ângulos distintos vencem nove sobrepostos.

Crédito

O padrão multi-persona-mais-revisão-cega-mais-presidente vem de Ollie Leman, através do episódio do Open Residency de Remy Gaskell sobre sistemas operacionais 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.

Habilidades Relacionadas