Community生产力与协作github.com

决策委员会

对决策进行结构化多视角评审,而非只得到一个令人信服的答案。在用户要求“召开委员会”、“提供各方观点”、“是否应该做X”、“压力测试这个决策”或“这是个好主意吗”时使用。

决策委员会 是什么?

该技能通过同时调用多个独立视角的智能体(如唱反调者、乐观者、执行者、客户、会计)来克服单一智能体倾向于生成连贯而非正确答案的弱点。每个视角独立给出建议和推理,然后通过盲审机制(剥离作者信息)让其他智能体评审,最后由一位“主席”智能体综合所有内容给出一个裁决,包括信心水平、最强反对论点以及后续行动。适用于成本高昂的决策叉(如架构选择、功能取舍、定价变更),建议在决策表述清晰且存在真正代价时运行。支持通过调整视角(如添加合规或安全专家)来匹配不同决策类型,并可扩展参与人数以适配决策的重要性。

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

Installed? Explore more 生产力与协作 skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

决策委员会 是做什么的?

此技能解决的问题

问智能体“为什么这是个好主意?”你会得到一个论证充分的肯定案例。问“为什么这是个坏主意?”你又会得到一个同样论证充分的否定案例。两者都很流畅,但都不是真正的判断。单一智能体是一个糟糕的顾问,因为它优化的目标是给出连贯的答案,而非正确的答案。

此技能运行几个独立的视角,让不知道谁写了什么的智能体进行评审,并最终产生一个裁决。

何时运行

真正有代价的分叉点:自建 vs. 采购、发布 vs. 保留、定价变更、某个功能是否过早推出、接下来该做什么。不适用于已有明确答案的问题。

步骤

1. 精确陈述决策

将其写成一个包含真实分叉点的句子。如果无法这样陈述,说明决策还不够清晰,无法进行评审——先解决这个问题。

收集已知信息:约束条件、已经尝试过的方案、哪些是可逆的、哪些是不可逆的。

2. 成立委员会——并行、独立

五个智能体,每个拥有真正不同的视角。它们绝不能看到彼此的答案。

角色职责
唱反调者假设此方案失败。是什么导致了失败?
乐观者假设此方案成功。它解锁了什么被低估的东西?
执行者谁来做这项工作、什么会出问题、用户时间的真实成本是多少?
客户实际付款的人在乎吗?他们会注意到吗?
会计成本是多少、回报是什么、机会成本是什么?

每个角色返回:一条建议、推理过程、以及一个能改变其想法的事实。

当决策需要时,可以替换某个角色——例如合规分叉使用监管视角,架构分叉使用安全视角。确保视角真正各不相同。

3. 盲审

剥离归属信息并打乱顺序。将匿名集合交给新的评审者。询问他们:哪个论点最强、哪个最弱、所有人都遗漏了什么?

盲审很重要——它能阻止评审者不自觉地向听起来最权威的角色靠拢。

4. 主席

最后一位智能体阅读各方观点和评审,并返回:

## 决策:<问题>

**裁决:** <用一句话说明结论>

**信心水平:** <高 | 中 | 低> — <原因>

**起决定性作用的论证:** <2-3句话>

**最有力的反对论点:** <公平陈述——不要设置稻草人>

**什么会改变这一点:** <能改变答案的特定事实或事件>

**如果我们要推进:** <第一个具体步骤>

5. 如实报告

如果委员会意见分裂,请说明它分裂了。强迫达成共识比坦诚的分歧更糟糕——大多数人宁愿看到真实的张力,然后自己做决定。

永远不要为了显得果断而制造虚假的一致。

规模调整

默认使用五个角色。较小的决策用三个,代价高昂或难以逆转的决策用七个。只有在视角真正不同时,增加角色才有帮助——五个不同的角度胜过九个重叠的角度。

致谢

多角色加盲审加主席的模式来自 Ollie Leman,经由 Remy Gaskell 在“Open Residency”关于智能体操作系统的播客中介绍。

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.

相关技能