关于 board-meeting
board-meeting 是面向创始人与高管决策的多 Agent 审议技能,通过分阶段流程收集独立观点、审查假设并形成待创始人确认的决策。它还包含决策跟踪与复杂度评估工具。
主要功能
- 01六阶段结构化审议流程
- 02按议题激活相关角色
- 03隔离收集各方意见
- 04批判审查与决策综合
- 05跟踪决策冲突及复查
- 06评估决策复杂度
适用场景
- 01讨论融资或市场扩张决策
- 02梳理跨部门争议
- 03审查待定会议并恢复处理
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill board-meeting安装后在 Claude Code 中输入/board-meeting确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
scripts/complexity_scorer.pydecision_tracker.pymeeting_simulator.py详细介绍
董事会会议协议
结构化的多 Agent 审议流程,可防止群体思维、记录少数意见,并产出清晰且可执行的决策。每个阶段都有明确目的、格式和不可跳过的规则。
关键词
董事会会议、管理层审议、战略决策、高管团队、多 Agent、创始人评审、决策提取、独立视角、防止群体思维、综合分析、批判性分析、结构化审议
先澄清
开始生成内容前,确认以下信息。如果有任何信息未知或含糊不清,请先询问——不要自行假设:
- 要做出的确切决策(用一句话表述)——整个协议旨在综合得出单一决策;主题模糊,综合结果也会模糊
- 要启用哪些角色——角色启用矩阵决定第二阶段会呈现哪些视角;名单不当会导致缺少关键声音或带来噪声
- 有哪些可用的数据和背景信息,以及哪些是推测的——第二阶段的意见会标注置信度和来源,因此必须区分已知事实与猜测
- 决策的可逆性和利害关系——据此判断是采用完整的 6 阶段协议,还是采用精简版咨询会议
停止规则:只询问最能影响结果的 2-3 项。如果用户说“直接起草”,就继续,并在文档开头列出你的假设。
6 阶段协议
PHASE 1: Context Gathering
|
PHASE 2: Independent Contributions (ISOLATED)
|
PHASE 3: Critic Analysis (Executive Mentor)
|
PHASE 4: Synthesis (Chief of Staff)
|
PHASE 5: Founder Review (FULL STOP -- human decides)
|
PHASE 6: Decision Extraction and Logging
阶段 1:收集背景信息
目的:在任何人发表意见前,加载所有相关背景信息。
Step 1: Load company context (if exists)
Step 2: Load decision history (Layer 2 ONLY -- NEVER raw transcripts)
Step 3: Reset session state -- no bleed from previous conversations
Step 4: Present agenda and activated roles
Step 5: Wait for founder confirmation before proceeding
角色启用矩阵
并非每次会议都需要所有角色出席。根据主题选择:
| 主题领域 | 启用 | 排除 |
|---|---|---|
| 市场扩张 | CEO、CMO、CFO、CRO、COO | CTO(除非涉及技术扩张) |
| 产品方向 | CEO、CPO、CTO、CMO | CFO(除非涉及预算问题) |
| 招聘 / 组织 | CEO、CHRO、CFO、COO | CMO、CTO(除非涉及其团队) |
| 定价 | CMO、CFO、CRO、CPO | CTO、CHRO |
| 技术 | CTO、CPO、CFO、CISO | CMO、CRO |
| 融资 | CEO、CFO、CRO | CISO、CHRO |
| 安全事件 | CEO、CTO、CISO、COO | CMO、CRO |
| 并购 | CEO、CFO、CTO、CHRO、COO | --(所有相关角色) |
出席人数上限:每次会议最多 6 个角色。超过 6 个会带来噪声,而非洞见。
阶段 2:独立意见(隔离进行)
关键规则:禁止交叉影响。每位顾问发表意见时不得查看其他人的输出。这是防止群体思维的主要机制。
意见提交顺序
1. Research/data gathering (if needed)
2. CMO -- market perspective
3. CFO -- financial perspective
4. CEO -- strategic perspective
5. CTO -- technical perspective
6. COO -- operational perspective
7. CHRO -- people perspective
8. CRO -- revenue perspective
9. CISO -- security/risk perspective
10. CPO -- product perspective
意见格式(严格遵循)
每位顾问的意见都必须遵循以下确切格式:
## [ROLE] -- [DATE]
Key Points (maximum 5):
1. [Finding] -- Confidence: [High/Medium/Low] -- Source: [data source]
2. [Finding] -- Confidence: [High/Medium/Low] -- Source: [data source]
3. [Finding] -- Confidence: [High/Medium/Low] -- Source: [data source]
Recommendation: [Clear position statement]
Confidence: [High / Medium / Low]
Key Assumption: [The one assumption this recommendation depends on]
What Would Change My Mind: [Specific condition or data point]
各角色的推理技巧
| 角色 | 技巧 | 运作方式 |
|---|---|---|
| CEO | 思维树 | 探索 3 种可能的未来,并逐一评估 |
| CFO | 思维链 | 逐步列出计算过程 |
| CMO | 思维递归 | 起草 -> 自我批评 -> 修改 |
| CPO | 第一性原理 | 分解并提炼用户的根本需求 |
| CRO | 思维链 | 必须明确列出销售管线的计算过程 |
| COO | 逐步推理 | 梳理运营流程 |
| CTO | 先分析再行动 | 研究 -> 分析 -> 建议 |
| CISO | 基于风险的分析 | 评估每个选项的概率 x 影响 |
| CHRO | 共情 + 数据 | 优先考虑对人的影响,再用指标验证 |
阶段 3:批判性分析
目的:执行导师同时接收第二阶段的所有输出,并进行对抗性审查。
批判者检查清单
| 检查项 | 问题 |
|---|---|
| 可疑的共识 | Agent 在哪里过于轻易地达成一致? |
| 共同假设 | 哪些假设被共同接受,却未经验证? |
| 缺失的声音 | 谁没有参与讨论?(客户的声音?一线运营人员?) |
| 未提及的风险 | 有什么风险没有人提到? |
| 领域越界 | 是否有 Agent 涉足自身领域之外? |
| 数据质量 | 哪些主张有数据支持,哪些只是推测? |
| 可逆性 | 是否有人评估过这个决策能否撤销? |
批判者输出格式
## CRITIC ANALYSIS
Consensus Assessment:
[Genuine agreement / Suspicious alignment / Split decision]
Unvalidated Assumptions:
1. [Assumption shared by multiple advisors but not verified]
2. [Assumption]
Missing Perspectives:
- [Voice or data point not represented]
Unmentioned Risks:
- [Risk nobody raised]
Domain Violations:
- [If any agent operated outside their domain]
The Uncomfortable Truth:
[The one thing nobody wants to say but needs to be said]
阶段 4:综合
目的:幕僚长将所有输入整理成可供决策的格式。
综合结构
## BOARD MEETING SYNTHESIS
Topic: [topic]
Date: [date]
Attendees: [roles]
### Decision Required
[One sentence: what must be decided]
### Perspectives Summary
| Role | Position | Confidence | Key Concern |
|------|----------|-----------|-------------|
| [Role] | [1-line summary] | [H/M/L] | [Top concern] |
| [Role] | [1-line summary] | [H/M/L] | [Top concern] |
### Where They Agree
[2-3 consensus points]
### Where They Disagree
[Named conflicts with each side's reasoning]
[What the disagreement is really about]
### Critic's View
[The uncomfortable truth from Phase 3]
### Recommended Decision
[Clear recommendation with rationale]
### Action Items (if approved)
1. [Action] -- Owner: [role] -- Deadline: [date]
2. [Action] -- Owner: [role] -- Deadline: [date]
3. [Action] -- Owner: [role] -- Deadline: [date]
### Your Call
[If you disagree with the recommendation, here are alternatives:]
Option A: [description] -- Trade-off: [what you gain/lose]
Option B: [description] -- Trade-off: [what you gain/lose]
阶段 5:创始人审阅
完全停止。等待创始人。在此之后,不得有任何 Agent 采取行动。
FOUNDER REVIEW
[Paste synthesis above]
Options:
[A] Approve as recommended
[M] Modify (specify changes)
[R] Reject (specify reason)
[Q] Ask follow-up question to specific role
[D] Defer decision (specify timeline)
阶段 5 规则
| 规则 | 理由 |
|---|---|
| 创始人的修正优先于所有 Agent 的提议 | 人类判断具有最终决定权 |
| 不得反驳创始人的决定 | Agent 提供建议,创始人做决定 |
| 闲置 30 分钟后自动以“待审阅”状态关闭 | 防止会议变成僵尸会议 |
| 创始人可随时重新开启 | 决策不受时间限制 |
| 后续问题交由具体角色处理 | 让讨论保持聚焦 |
阶段 6:提取决策
目的:创始人批准后,提取并记录所有决策。
Step 1: Write full transcript to Layer 1
--> memory/board-meetings/YYYY-MM-DD-raw.md
Step 2: Run conflict detection against existing decisions
--> Check for DO_NOT_RESURFACE violations
--> Check for topic contradictions
--> Check for owner conflicts
Step 3: Surface any conflicts to founder for resolution
Step 4: Append approved decisions to Layer 2
--> memory/board-meetings/decisions.md
Step 5: Mark rejected proposals with DO_NOT_RESURFACE
Step 6: Confirm to founder:
"Meeting concluded. Logged: [N] decisions, [M] action items,
[K] DO_NOT_RESURFACE flags."
故障模式参考
| 故障 | 检测方式 | 修复方法 |
|---|---|---|
| 群体思维 | 所有顾问都意见一致,没有分歧 | 重新独立执行阶段 2;强制提出“最有力的反方论据” |
| 分析瘫痪 | 每位顾问的讨论超过 5 个要点 | 限制为 5 个要点;即使置信度较低,也必须给出建议 |
| 纠结枝节 | 讨论次要事项,主要决策却被搁置 | 记录为异步行动;返回主要议程 |
| 角色越界 | CFO 做出产品决策,CTO 制定价格 | 由批评者在阶段 3 指出;不纳入综合 |
| 层级污染 | 阶段 1 加载原始记录 | 严格规定:仅使用 decisions.md。绝不使用原始记录。 |
| 创始人缺席 | 阶段 5 超时 | 自动以待审阅状态关闭。没有创始人,不做决策。 |
| 上下文过时 | 未加载公司上下文 | 阶段 1 必须检查上下文 |
| 缺少角色 | 未启用关键视角 | 幕僚长根据路由矩阵审查议题 |
会议频率
| 触发条件 | 会议类型 | 典型时长 |
|---|---|---|
| 按计划每季度召开 | 全面战略审查 | 2-3 小时 |
| 复杂度评分 >= 8 | 按需战略会议 | 1-2 小时 |
| 跨职能冲突 | 冲突解决会议 | 1 小时 |
| 危机或紧急决策 | 紧急会议 | 30-60 分钟 |
| 创始人请求 | 任意议题 | 不定 |
危险信号
- 董事会会议持续未能做出任何决策——会议流于形式
- 同一议题在 3 场或更多会议中反复讨论——逃避决策
- 阶段 2 的所有贡献完全一致——独立讨论遭到破坏,或议题无关紧要
- 未进行阶段 3(批评者)——存在群体思维风险
- 创始人跳过阶段 5——决策缺乏问责
- 决策虽已记录但从未审查——决策记录器未正常运行
- 会议总是包含所有角色——议题选择机制未发挥作用
输出产物
| 请求 | 交付内容 |
|---|---|
| “围绕 [topic] 召集董事会” | 执行完整的 6 阶段流程 |
| “快速咨询会议” | 精简流程:阶段 1-2-4-5(跳过批评者) |
| “审查过去的会议” | 加载第 1 层原始记录(仅限明确请求) |
| “我们对 [topic] 做出了什么决定?” | 搜索第 2 层决策历史 |
| “恢复待处理的会议” | 重新加载包含待审阅综合内容的阶段 5 |
工具参考
meeting_simulator.py
验证角色启用情况、贡献完整性和阶段顺序。
# Simulate with defaults
python scripts/meeting_simulator.py
# Specify topic and complexity
python scripts/meeting_simulator.py --topic "Series B timing" --type fundraising --complexity 9
# Specify activated roles
python scripts/meeting_simulator.py --type m_and_a --roles CEO CFO CTO CHRO
# List all topic types and required roles
python scripts/meeting_simulator.py --list-topics
# JSON output
python scripts/meeting_simulator.py --type strategy --json
decision_tracker.py
跟踪董事会决策,检测冲突,并标记逾期审查和行动。
# Track demo decisions
python scripts/decision_tracker.py
# From decision log file
python scripts/decision_tracker.py --input decisions.json
# JSON output
python scripts/decision_tracker.py --json
complexity_scorer.py
评估决策复杂度,以确定单顾问、双顾问、多顾问或董事会路由方式。
# Score with CLI flags
python scripts/complexity_scorer.py --topic "Market expansion" --domains 2 --reversibility 2 --financial 1 --team 2 --urgency 0
# Add modifiers
python scripts/complexity_scorer.py --topic "Acquisition" --domains 2 --reversibility 2 --financial 2 --team 2 --urgency 1 --modifiers cross_functional external_stakeholders sets_precedent
# JSON output
python scripts/complexity_scorer.py --topic "Pricing change" --json
故障排除
| 问题 | 可能原因 | 修复方法 |
|---|---|---|
| 第 2 阶段所有顾问意见一致,没有任何分歧 | 群体思维或议题过于简单;可能已违反隔离要求 | 重新运行第 2 阶段,要求每个角色都提出「最有力的反方论点」 |
| 讨论中每位顾问提出的要点超过 5 个 | 分析瘫痪;未执行上限 | 严格限制为 5 个关键要点;即使信心度低,也必须给出建议 |
| 第 5 阶段超时,创始人仍未回复 | 创始人缺席或回避决策 | 30 分钟后自动关闭为「待审核」;未经创始人同意不得做出决策 |
| 同一议题在 3 场或更多会议中反复讨论 | 回避决策或未提出新数据 | 升级处理:强制做出决策,或正式延期并说明时间安排 |
| 决策已记录但从未审核 | 决策记录器未纳入会议节奏 | 在第 1 阶段的上下文加载中加入「审核以往决策」 |
| 角色超出自身职责范围 | 未进行批评者分析,或批评者未发现问题 | 严格执行第 3 阶段的批评者清单;明确标记越权行为 |
成功标准
- 每次董事会会议至少产出 1 项已记录的决策,并注明负责人、截止日期和审核日期
- 第 2 阶段的意见独立生成(每季度交叉影响事件为零)
- 第 3 阶段的批评者分析每次会议至少识别 1 项未经验证的假设
- 综合结论呈现后 30 分钟内记录创始人的批准、修改或否决
- 决策历史中不存在相互冲突的有效决策(检测并解决冲突)
- 标准战略评审会议时长不超过 2 小时,决议会议时长不超过 1 小时
- 90% 以上已记录决策的行动项都在规定截止日期前完成
范围与限制
范围内:多 Agent 审议协议、角色激活矩阵、意见格式、批评者分析、综合结论、决策提取、决策冲突检测、会议模拟。
范围外:实际 AI Agent 编排(这是协议规范,不是运行时代码)、实时会议主持、视频/音频录制、外部董事管理。
限制:该协议假设所有顾问意见都以文本格式提供。复杂度评分可提供路由指导,但无法考虑政治动态。决策冲突检测基于议题的精确匹配;不同议题之间的语义冲突需要人工判断。
集成点
| 技能 | 集成方式 |
|---|---|
chief-of-staff | 将复杂度评分为 9-10 的问题路由至董事会会议协议 |
decision-logger | 第 6 阶段将决策直接输入双层决策记忆 |
board-deck-builder | 董事会演示文稿章节为第 1 阶段提供会前阅读材料 |
executive-mentor | 第 3 阶段的批评者分析可由 Executive Mentor 技能执行 |
ceo-advisor through ciso-advisor | 所有 C 级高管顾问在第 2 阶段独立提供意见 |
strategic-alignment | 验证会议决策是否符合战略目标 |