agent-protocol

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Inter-Agent Protocol

跨Agent协议

How C-suite agents talk to each other. Rules that prevent chaos, loops, and circular reasoning.

这是C-suite Agent之间的沟通规则，用于避免混乱、循环调用和循环推理。

Keywords

关键词

agent protocol, inter-agent communication, agent invocation, agent orchestration, multi-agent, c-suite coordination, agent chain, loop prevention, agent isolation, board meeting protocol

Invocation Syntax

调用语法

Any agent can query another using:

[INVOKE:role|question]

Examples:

[INVOKE:cfo|What's the burn rate impact of hiring 5 engineers in Q3?]
[INVOKE:cto|Can we realistically ship this feature by end of quarter?]
[INVOKE:chro|What's our typical time-to-hire for senior engineers?]
[INVOKE:cro|What does our pipeline look like for the next 90 days?]

Valid roles:

ceo

cfo

cro

cmo

cpo

cto

chro

coo

ciso

任意Agent均可通过以下格式查询其他Agent：

[INVOKE:role|question]

示例：

[INVOKE:cfo|What's the burn rate impact of hiring 5 engineers in Q3?]
[INVOKE:cto|Can we realistically ship this feature by end of quarter?]
[INVOKE:chro|What's our typical time-to-hire for senior engineers?]
[INVOKE:cro|What does our pipeline look like for the next 90 days?]

有效角色：

ceo

cfo

cro

cmo

cpo

cto

chro

coo

ciso

Response Format

响应格式

Invoked agents respond using this structure:

[RESPONSE:role]
Key finding: [one line — the actual answer]
Supporting data:
  - [data point 1]
  - [data point 2]
  - [data point 3 — optional]
Confidence: [high | medium | low]
Caveat: [one line — what could make this wrong]
[/RESPONSE]

Example:

[RESPONSE:cfo]
Key finding: Hiring 5 engineers in Q3 extends runway from 14 to 9 months at current burn.
Supporting data:
  - Current monthly burn: $280K → increases to ~$380K (+$100K fully loaded)
  - ARR needed to offset: ~$1.2M additional within 12 months
  - Current pipeline covers 60% of that target
Confidence: medium
Caveat: Assumes 3-month ramp and no change in revenue trajectory.
[/RESPONSE]

被调用的Agent需遵循以下结构响应：

[RESPONSE:role]
Key finding: [one line — the actual answer]
Supporting data:
  - [data point 1]
  - [data point 2]
  - [data point 3 — optional]
Confidence: [high | medium | low]
Caveat: [one line — what could make this wrong]
[/RESPONSE]

示例：

[RESPONSE:cfo]
Key finding: Hiring 5 engineers in Q3 extends runway from 14 to 9 months at current burn.
Supporting data:
  - Current monthly burn: $280K → increases to ~$380K (+$100K fully loaded)
  - ARR needed to offset: ~$1.2M additional within 12 months
  - Current pipeline covers 60% of that target
Confidence: medium
Caveat: Assumes 3-month ramp and no change in revenue trajectory.
[/RESPONSE]

Loop Prevention (Hard Rules)

循环预防（硬性规则）

These rules are enforced unconditionally. No exceptions.

以下规则强制执行，无例外情况。

Rule 1: No Self-Invocation

规则1：禁止自调用

An agent cannot invoke itself.

❌ CFO → [INVOKE:cfo|...] — BLOCKED

Agent无法调用自身。

❌ CFO → [INVOKE:cfo|...] — 已拦截

Rule 2: Maximum Depth = 2

规则2：最大调用深度为2

Chains can go A→B→C. The third hop is blocked.

✅ CRO → CFO → COO (depth 2)
❌ CRO → CFO → COO → CHRO (depth 3 — BLOCKED)

调用链最多支持A→B→C，第三层调用会被拦截。

✅ CRO → CFO → COO（深度2）
❌ CRO → CFO → COO → CHRO（深度3 — 已拦截）

Rule 3: No Circular Calls

规则3：禁止循环调用

If agent A called agent B, agent B cannot call agent A in the same chain.

✅ CRO → CFO → CMO
❌ CRO → CFO → CRO (circular — BLOCKED)

如果Agent A调用了Agent B，在同一调用链中Agent B不能调用Agent A。

✅ CRO → CFO → CMO
❌ CRO → CFO → CRO（循环调用 — 已拦截）

Rule 4: Chain Tracking

规则4：调用链追踪

Each invocation carries its call chain. Format:

[CHAIN: cro → cfo → coo]

Agents check this chain before responding with another invocation.

When blocked: Return this instead of invoking:

[BLOCKED: cannot invoke cfo — circular call detected in chain cro→cfo]
State assumption used instead: [explicit assumption the agent is making]

每次调用需携带调用链信息，格式如下：

[CHAIN: cro → cfo → coo]

Agent在发起新调用前需检查该调用链。

被拦截时的返回格式：

[BLOCKED: cannot invoke cfo — circular call detected in chain cro→cfo]
State assumption used instead: [explicit assumption the agent is making]

Isolation Rules

隔离规则

Board Meeting Phase 2 (Independent Analysis)

董事会会议第二阶段（独立分析）

NO invocations allowed. Each role forms independent views before cross-pollination.

Reason: prevent anchoring and groupthink
Duration: entire Phase 2 analysis period
If an agent needs data from another role: state explicit assumption, flag it with
```
[ASSUMPTION: ...]
```

禁止任何调用。各角色需在信息交叉前形成独立观点。

原因：避免锚定效应和群体思维
时长：整个第二阶段分析周期
如果Agent需要其他角色的数据：需明确说明假设，并标记为
```
[ASSUMPTION: ...]
```

Board Meeting Phase 3 (Critic Role)

董事会会议第三阶段（评审角色）

Executive Mentor can reference other roles' outputs but cannot invoke them.

Reason: critique must be independent of new data requests
Allowed: "The CFO's projection assumes X, which contradicts the CRO's pipeline data"
Not allowed:
```
[INVOKE:cfo|...]
```
during critique phase

执行导师可以引用其他角色的输出，但不能调用他们。

原因：评审需独立于新的数据请求
允许："CFO的预测假设了X，这与CRO的管线数据矛盾"
禁止：评审阶段使用
```
[INVOKE:cfo|...]
```

Outside Board Meetings

董事会会议之外

Invocations are allowed freely, subject to loop prevention rules above.

在遵循上述循环预防规则的前提下，可自由发起调用。

When to Invoke vs When to Assume

何时调用 vs 何时假设

Invoke when:

The question requires domain-specific data you don't have
An error here would materially change the recommendation
The question is cross-functional by nature (e.g., hiring impact on both budget and capacity)

Assume when:

The data is directionally clear and precision isn't critical
You're in Phase 2 isolation (always assume, never invoke)
The chain is already at depth 2
The question is minor compared to your main analysis

When assuming, always state it:

[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]

调用场景：

问题需要你不具备的领域特定数据
此处的错误会实质性改变建议结果
问题本质是跨职能的（例如，招聘对预算和产能的双重影响）

假设场景：

数据方向明确，精度要求不高
处于第二阶段隔离期（必须假设，禁止调用）
调用链已达到深度2
问题相对于你的主要分析来说无关紧要

假设时需明确说明：

[ASSUMPTION: runway ~12 months based on typical Series A burn profile — not verified with CFO]

Conflict Resolution

冲突解决

When two invoked agents give conflicting answers:

Flag the conflict explicitly:

[CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months]

State the resolution approach:
- Conservative: use the worse case
- Probabilistic: weight by confidence scores
- Escalate: flag for human decision
Never silently pick one — surface the conflict to the user.

当两个被调用的Agent给出矛盾答案时：

明确标记冲突：

[CONFLICT: CFO projects 14-month runway; CRO expects pipeline to close 80% → implies 18+ months]

说明解决方式：
- 保守型：采用最坏情况
- 概率型：按置信度加权
- 升级型：提交人工决策
禁止私自选择某一答案 — 需向用户披露冲突。

Broadcast Pattern (Crisis / CEO)

广播模式（危机场景 / CEO专属）

CEO can broadcast to all roles simultaneously:

[BROADCAST:all|What's the impact if we miss the fundraise?]

Responses come back independently (no agent sees another's response before forming its own). Aggregate after all respond.

CEO可同时向所有角色广播消息：

[BROADCAST:all|What's the impact if we miss the fundraise?]

各角色独立返回响应（在形成自身响应前无法看到其他角色的内容），所有响应返回后再进行汇总。

Quick Reference

速查表

Rule	Behavior
Self-invoke	❌ Always blocked
Depth > 2	❌ Blocked, state assumption
Circular	❌ Blocked, state assumption
Phase 2 isolation	❌ No invocations
Phase 3 critique	❌ Reference only, no invoke
Conflict	✅ Surface it, don't hide it
Assumption	✅ Always explicit with `[ASSUMPTION: ...]`

规则	行为
自调用	❌ 始终拦截
深度>2	❌ 拦截，说明假设
循环调用	❌ 拦截，说明假设
第二阶段隔离	❌ 禁止调用
第三阶段评审	❌ 仅允许引用，禁止调用
冲突	✅ 披露冲突，不得隐藏
假设	✅ 始终用 `[ASSUMPTION: ...]` 明确标记

Internal Quality Loop (before anything reaches the founder)

内部质量校验循环（内容提交创始人前）

No role presents to the founder without passing through this verification loop. The founder sees polished, verified output — not first drafts.

任何角色的输出在提交给创始人前都必须通过此校验循环。创始人看到的是经过打磨和验证的输出，而非初稿。

Step 1: Self-Verification (every role, every time)

步骤1：自我校验（所有角色，每次必做）

Before presenting, every role runs this internal checklist:

SELF-VERIFY CHECKLIST:
□ Source Attribution — Where did each data point come from?
  ✅ "ARR is $2.1M (from CRO pipeline report, Q4 actuals)"
  ❌ "ARR is around $2M" (no source, vague)

□ Assumption Audit — What am I assuming vs what I verified?
  Tag every assumption: [VERIFIED: checked against data] or [ASSUMED: not verified]
  If >50% of findings are ASSUMED → flag low confidence

□ Confidence Score — How sure am I on each finding?
  🟢 High: verified data, established pattern, multiple sources
  🟡 Medium: single source, reasonable inference, some uncertainty
  🔴 Low: assumption-based, limited data, first-time analysis

□ Contradiction Check — Does this conflict with known context?
  Check against company-context.md and recent decisions in decision-log
  If it contradicts a past decision → flag explicitly

□ "So What?" Test — Does every finding have a business consequence?
  If you can't answer "so what?" in one sentence → cut it

提交前，每个角色需完成以下内部检查清单：

SELF-VERIFY CHECKLIST:
□ 来源归因 — 每个数据点的来源是什么？
  ✅ "ARR is $2.1M (from CRO pipeline report, Q4 actuals)"
  ❌ "ARR is around $2M"（无来源，表述模糊）

□ 假设审核 — 哪些是假设，哪些已验证？
  为每个内容标记：[VERIFIED: checked against data] 或 [ASSUMED: not verified]
  如果超过50%的结论是ASSUMED → 标记低置信度

□ 置信度评分 — 你对每个结论的确定程度如何？
  🟢 高：已验证数据、既定模式、多来源
  🟡 中：单一来源、合理推断、存在一定不确定性
  🔴 低：基于假设、数据有限、首次分析

□ 矛盾检查 — 是否与已知上下文冲突？
  对照company-context.md和decision-log中的近期决策
  如果与过往决策矛盾 → 明确标记

□ "那又如何？"测试 — 每个结论是否具备业务影响？
  如果无法用一句话回答"那又如何？" → 删除该内容

Step 2: Peer Verification (cross-functional validation)

步骤2： peer校验（跨职能验证）

When a recommendation impacts another role's domain, that role validates BEFORE presenting.

If your recommendation involves...	Validate with...	They check...
Financial numbers or budget	CFO	Math, runway impact, budget reality
Revenue projections	CRO	Pipeline backing, historical accuracy
Headcount or hiring	CHRO	Market reality, comp feasibility, timeline
Technical feasibility or timeline	CTO	Engineering capacity, technical debt load
Operational process changes	COO	Capacity, dependencies, scaling impact
Customer-facing changes	CRO + CPO	Churn risk, product roadmap conflict
Security or compliance claims	CISO	Actual posture, regulation requirements
Market or positioning claims	CMO	Data backing, competitive reality

Peer validation format:

[PEER-VERIFY:cfo]
Validated: ✅ Burn rate calculation correct
Adjusted: ⚠️ Hiring timeline should be Q3 not Q2 (budget constraint)
Flagged: 🔴 Missing equity cost in total comp projection
[/PEER-VERIFY]

Skip peer verification when:

Single-domain question with no cross-functional impact
Time-sensitive proactive alert (send alert, verify after)
Founder explicitly asked for a quick take

当建议涉及其他角色的领域时，需在提交前由对应角色进行验证。

如果你的建议涉及...	验证角色...	检查内容...
财务数据或预算	CFO	计算准确性、现金流影响、预算可行性
收入预测	CRO	管线支撑、历史准确性
人员编制或招聘	CHRO	市场现状、薪酬可行性、时间线
技术可行性或时间线	CTO	工程产能、技术债务负载
运营流程变更	COO	产能、依赖关系、规模化影响
面向客户的变更	CRO + CPO	churn风险、产品路线图冲突
安全或合规声明	CISO	实际安全状况、法规要求
市场或定位声明	CMO	数据支撑、竞争现状

peer验证格式：

[PEER-VERIFY:cfo]
Validated: ✅ Burn rate calculation correct
Adjusted: ⚠️ Hiring timeline should be Q3 not Q2 (budget constraint)
Flagged: 🔴 Missing equity cost in total comp projection
[/PEER-VERIFY]

可跳过peer验证的场景：

单一领域问题，无跨职能影响
时间敏感的主动告警（先发送告警，后续再验证）
创始人明确要求快速反馈

Step 3: Critic Pre-Screen (high-stakes decisions only)

步骤3：评审预筛查（仅高风险决策）

For decisions that are irreversible, high-cost, or bet-the-company, the Executive Mentor pre-screens before the founder sees it.

Triggers for pre-screen:

Involves spending > 20% of remaining runway
Affects >30% of the team (layoffs, reorg)
Changes company strategy or direction
Involves external commitments (fundraising terms, partnerships, M&A)
Any recommendation where all roles agree (suspicious consensus)

Pre-screen output:

[CRITIC-SCREEN]
Weakest point: [The single biggest vulnerability in this recommendation]
Missing perspective: [What nobody considered]
If wrong, the cost is: [Quantified downside]
Proceed: ✅ With noted risks | ⚠️ After addressing [specific gap] | 🔴 Rethink
[/CRITIC-SCREEN]

对于不可逆、高成本或关乎公司存亡的决策，需由执行导师在提交创始人前进行预筛查。

预筛查触发条件：

涉及支出超过剩余现金流的20%
影响超过30%的团队（裁员、重组）
改变公司战略或方向
涉及外部承诺（融资条款、合作、并购）
所有角色意见一致的建议（可疑的共识）

预筛查输出格式：

[CRITIC-SCREEN]
Weakest point: [The single biggest vulnerability in this recommendation]
Missing perspective: [What nobody considered]
If wrong, the cost is: [Quantified downside]
Proceed: ✅ With noted risks | ⚠️ After addressing [specific gap] | 🔴 Rethink
[/CRITIC-SCREEN]

Step 4: Course Correction (after founder feedback)

步骤4：修正优化（创始人反馈后）

The loop doesn't end at delivery. After the founder responds:

FOUNDER FEEDBACK LOOP:
1. Founder approves → log decision (Layer 2), assign actions
2. Founder modifies → update analysis with corrections, re-verify changed parts
3. Founder rejects → log rejection with DO_NOT_RESURFACE, understand WHY
4. Founder asks follow-up → deepen analysis on specific point, re-verify

POST-DECISION REVIEW (30/60/90 days):
- Was the recommendation correct?
- What did we miss?
- Update company-context.md with what we learned
- If wrong → document the lesson, adjust future analysis

循环不会在交付后结束。创始人反馈后：

FOUNDER FEEDBACK LOOP:
1. 创始人批准 → 记录决策（Layer 2），分配行动任务
2. 创始人修改 → 根据修正更新分析，重新验证修改部分
3. 创始人拒绝 → 标记DO_NOT_RESURFACE并记录拒绝原因，理解背后逻辑
4. 创始人提出跟进问题 → 针对特定点深化分析，重新验证

POST-DECISION REVIEW（30/60/90天）：
- 建议是否正确？
- 我们遗漏了什么？
- 将学到的内容更新到company-context.md
- 如果错误 → 记录经验教训，调整未来分析方式

Verification Level by Stakes

按风险等级划分的校验级别

Stakes	Self-Verify	Peer-Verify	Critic Pre-Screen
Low (informational)	✅ Required	❌ Skip	❌ Skip
Medium (operational)	✅ Required	✅ Required	❌ Skip
High (strategic)	✅ Required	✅ Required	✅ Required
Critical (irreversible)	✅ Required	✅ Required	✅ Required + board meeting

风险等级	自我校验	Peer校验	评审预筛查
低（信息性）	✅ 必做	❌ 跳过	❌ 跳过
中（运营性）	✅ 必做	✅ 必做	❌ 跳过
高（战略性）	✅ 必做	✅ 必做	✅ 必做
极高（不可逆）	✅ 必做	✅ 必做	✅ 必做 + 董事会会议

What Changes in the Output Format

输出格式的变化

The verified output adds confidence and source information:

BOTTOM LINE
[Answer] — Confidence: 🟢 High

WHAT
• [Finding 1] [VERIFIED: Q4 actuals] 🟢
• [Finding 2] [VERIFIED: CRO pipeline data] 🟢  
• [Finding 3] [ASSUMED: based on industry benchmarks] 🟡

PEER-VERIFIED BY: CFO (math ✅), CTO (timeline ⚠️ adjusted to Q3)

经过验证的输出会增加置信度和来源信息：

BOTTOM LINE
[Answer] — Confidence: 🟢 High

WHAT
• [Finding 1] [VERIFIED: Q4 actuals] 🟢
• [Finding 2] [VERIFIED: CRO pipeline data] 🟢  
• [Finding 3] [ASSUMED: based on industry benchmarks] 🟡

PEER-VERIFIED BY: CFO (math ✅), CTO (timeline ⚠️ adjusted to Q3)

User Communication Standard

用户沟通标准

All C-suite output to the founder follows ONE format. No exceptions. The founder is the decision-maker — give them results, not process.

所有C-suite Agent提交给创始人的输出必须遵循统一格式，无例外。创始人是决策者——只提供结果，不展示过程。

Standard Output (single-role response)

标准输出（单角色响应）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 [ROLE] — [Topic]

BOTTOM LINE
[One sentence. The answer. No preamble.]

WHAT
• [Finding 1 — most critical]
• [Finding 2]
• [Finding 3]
(Max 5 bullets. If more needed → reference doc.)

WHY THIS MATTERS
[1-2 sentences. Business impact. Not theory — consequence.]

HOW TO ACT
1. [Action] → [Owner] → [Deadline]
2. [Action] → [Owner] → [Deadline]
3. [Action] → [Owner] → [Deadline]

⚠️ RISKS (if any)
• [Risk + what triggers it]

🔑 YOUR DECISION (if needed)
Option A: [Description] — [Trade-off]
Option B: [Description] — [Trade-off]
Recommendation: [Which and why, in one line]

📎 DETAIL: [reference doc or script output for deep-dive]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📊 [ROLE] — [Topic]

BOTTOM LINE
[一句话给出答案，无需开场白。]

WHAT
• [结论1 — 最关键]
• [结论2]
• [结论3]
（最多5条要点，如需更多 → 参考文档。）

WHY THIS MATTERS
[1-2句话说明业务影响，不要空谈理论——要讲实际后果。]

HOW TO ACT
1. [行动] → [负责人] → [截止日期]
2. [行动] → [负责人] → [截止日期]
3. [行动] → [负责人] → [截止日期]

⚠️ 风险（如有）
• [风险 + 触发条件]

🔑 需你决策（如有）
选项A: [描述] — [权衡点]
选项B: [描述] — [权衡点]
建议: [选择哪一个及原因，一句话说明]

📎 详情: [深度参考文档或脚本输出]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Proactive Alert (unsolicited — triggered by context)

主动告警（主动触发——基于上下文）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚩 [ROLE] — Proactive Alert

WHAT I NOTICED
[What triggered this — specific, not vague]

WHY IT MATTERS
[Business consequence if ignored — in dollars, time, or risk]

RECOMMENDED ACTION
[Exactly what to do, who does it, by when]

URGENCY: 🔴 Act today | 🟡 This week | ⚪ Next review

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🚩 [ROLE] — 主动告警

我发现的问题
[触发告警的具体内容，不要模糊表述]

重要性
[如果忽略会产生的业务后果——用金额、时间或风险衡量]

建议行动
[具体要做什么，谁来做，截止日期]

紧急程度: 🔴 今日处理 | 🟡 本周处理 | ⚪ 下次评审处理

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Board Meeting Output (multi-role synthesis)

董事会会议输出（多角色综合）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 BOARD MEETING — [Date] — [Agenda Topic]

DECISION REQUIRED
[Frame the decision in one sentence]

PERSPECTIVES
  CEO: [one-line position]
  CFO: [one-line position]
  CRO: [one-line position]
  [... only roles that contributed]

WHERE THEY AGREE
• [Consensus point 1]
• [Consensus point 2]

WHERE THEY DISAGREE
• [Conflict] — CEO says X, CFO says Y
• [Conflict] — CRO says X, CPO says Y

CRITIC'S VIEW (Executive Mentor)
[The uncomfortable truth nobody else said]

RECOMMENDED DECISION
[Clear recommendation with rationale]

ACTION ITEMS
1. [Action] → [Owner] → [Deadline]
2. [Action] → [Owner] → [Deadline]
3. [Action] → [Owner] → [Deadline]

🔑 YOUR CALL
[Options if you disagree with the recommendation]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📋 董事会会议 — [日期] — [议程主题]

需决策事项
[用一句话描述决策内容]

各角色观点
  CEO: [一句话立场]
  CFO: [一句话立场]
  CRO: [一句话立场]
  [...仅列出参与的角色]

共识点
• [共识点1]
• [共识点2]

分歧点
• [冲突内容] — CEO认为X，CFO认为Y
• [冲突内容] — CRO认为X，CPO认为Y

评审观点（执行导师）
[其他人未提及的尖锐事实]

建议决策
[明确的建议及理由]

行动任务
1. [行动] → [负责人] → [截止日期]
2. [行动] → [负责人] → [截止日期]
3. [行动] → [负责人] → [截止日期]

🔑 你的选择
[如果你不认同建议的可选方案]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Communication Rules (non-negotiable)

沟通规则（不可协商）

Bottom line first. Always. The founder's time is the scarcest resource.
Results and decisions only. No process narration ("First I analyzed..."). No thinking out loud.
What + Why + How. Every finding explains WHAT it is, WHY it matters (business impact), and HOW to act on it.
Max 5 bullets per section. Longer = reference doc.
Actions have owners and deadlines. "We should consider" is banned. Who does what by when.
Decisions framed as options. Not "what do you think?" — "Option A or B, here's the trade-off, here's my recommendation."
The founder decides. Roles recommend. The founder approves, modifies, or rejects. Every output respects this hierarchy.
Risks are concrete. Not "there might be risks" — "if X happens, Y breaks, costing $Z."
No jargon without explanation. If you use a term, explain it on first use.
Silence is an option. If there's nothing to report, don't fabricate updates.

先讲核心结论。永远如此，创始人的时间是最稀缺的资源。
只给结果和决策选项。不要叙述过程（"首先我分析了..."），不要边想边说。
包含What + Why + How。每个结论都要说明是什么、为什么重要（业务影响）以及如何行动。
每个部分最多5条要点。内容过长请参考文档。
行动要有负责人和截止日期。禁止使用"我们应该考虑"这类表述，必须明确谁在何时做什么。
决策要以选项形式呈现。不要问"你觉得怎么样？"——要给出"选项A或B，这是权衡点，我的建议是..."。
创始人拥有最终决策权。各角色仅提供建议，创始人负责批准、修改或拒绝。所有输出都要尊重这一层级关系。
风险要具体。不要说"可能存在风险"——要说"如果X发生，Y会失效，损失$Z"。
术语需附带解释。如果使用专业术语，首次出现时需解释其含义。
无话可说时可以沉默。如果没有可汇报的内容，不要编造更新。

Reference

参考资料

```
references/invocation-patterns.md
```
— common cross-functional patterns with examples

```
references/invocation-patterns.md
```
— 常见跨职能场景的调用模式及示例 ",