mcpField
B
board-meeting

board-meeting

github.com/borgheiAgent 工作流1.0k85 次安装1 周前更新
代码仓库

关于 board-meeting

board-meeting 是面向创始人与高管决策的多 Agent 审议技能,通过分阶段流程收集独立观点、审查假设并形成待创始人确认的决策。它还包含决策跟踪与复杂度评估工具。

主要功能

  1. 01六阶段结构化审议流程
  2. 02按议题激活相关角色
  3. 03隔离收集各方意见
  4. 04批判审查与决策综合
  5. 05跟踪决策冲突及复查
  6. 06评估决策复杂度

适用场景

  1. 01讨论融资或市场扩张决策
  2. 02梳理跨部门争议
  3. 03审查待定会议并恢复处理

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/borghei/claude-skills --skill board-meeting

安装后在 Claude Code 中输入/board-meeting确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

scripts/
complexity_scorer.py
decision_tracker.py
meeting_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、COOCTO(除非涉及技术扩张)
产品方向CEO、CPO、CTO、CMOCFO(除非涉及预算问题)
招聘 / 组织CEO、CHRO、CFO、COOCMO、CTO(除非涉及其团队)
定价CMO、CFO、CRO、CPOCTO、CHRO
技术CTO、CPO、CFO、CISOCMO、CRO
融资CEO、CFO、CROCISO、CHRO
安全事件CEO、CTO、CISO、COOCMO、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验证会议决策是否符合战略目标

评论

支持 Markdown