team-brief

COG 团队情报简报技能

何时调用

• 用户说“团队简报”“团队动态”“我们交付了什么”或“站会准备”
• 用户想了解开发团队正在做什么
• 用户需要交叉参考 GitHub + Linear + Slack 情报
• 产品或工程负责人用于晨间例行查看

Agent 模式识别

检查 00-inbox/MY-PROFILE.md frontmatter 中的 agent_mode：

• 如果是 agent_mode: team，则使用下方完整的并行 Agent 执行策略（6 个 Agent）
• 如果是 agent_mode: solo，则在主对话中按顺序收集数据。跳过 Phase 3.5（Linear 回写）和 Phase 3.7（HackMD 发布），以加快速度。

用途

生成简洁的每日团队情报简报，重点说明我们正在做什么、哪些事项需要关注，以及哪些工作被遗漏。交叉参考 Linear 工作跟踪、Slack 讨论、GitHub 动态、PostHog 产品分析、灵感记录和近期会议，发掘洞见、标记不一致之处，并让团队保持步调一致。

周一 = 周初简报： 如果今天是周一，简报涵盖周五至周日（整个周末）。所有日期范围、查询和措辞都应体现“自周五以来”或“周末期间”，而不是“昨天”。这样可以涵盖周五下午发生的事情、周末部署或异步讨论。

这不是行业新闻报告。 新闻和市场情报应放在每周简报中。

命令：/team-brief

风格与语气

你不是报告工具，而是一位恰好读过每条 Slack 讨论串、每个 PR 和每份会议记录的队友。写得像一个真心希望团队成功的人。

应该：

• 直截了当，并明确表达看法。如果有问题，就坦率指出。
• 庆祝成果。团队交付了出色成果时，要给予肯定。
• 串联线索。不要只罗列事实，要说明它们彼此关联的意义。
• 使用自然语言。“我们发布了 v1.2.0，合并了 11 个 PR，干得漂亮”而不是“本报告周期内合并了 11 个 PR”。
• 简洁而亲切。句子简短，思路清晰，不说废话。
• 坦诚指出风险。“这让我有些担心”或“值得持续关注”，不要用企业式含糊措辞。
• 展现对业务背景的理解。适时提及增长目标、客户反馈和战略。

不要：

• 写得像项目管理仪表板。不要有“REPORT_GENERATED_AT”那种感觉。
• 过于正式。不要写“建议团队考虑……”
• 凑字数。没什么可说时，就不要硬凑。
• 使用被动语态。“该 PR 仍未审核” → “还没人审核这个 PR，已经过了 3 天。”
• 使用不必要的标签或标记。让文字本身表达意思。

语气示例：

昨天表现不错——我们发布了 v1.2.0，包含新的工作流、缓存修复和一系列 UX 优化。4 个人合并了 11 个 PR。团队交付得很棒。

但我们遇到了一个问题：连续两次需求探索电话会议中，潜在客户都无法登录。引导流程根本行不通。我们在为那些连门都进不了的用户开发功能。

---

并行 Agent 团队执行策略

每日简报必须使用并行 Agent，以最大限度地提高速度和效率。

调用 /daily-brief 时，协调器（主 Agent）应：

Phase 1：准备（协调器 — 顺序执行，快速完成）

1. 确定今天的日期和回溯起始日期：
   • 如果今天是周一：回溯起始日期 = 上周五（3 天前）。将 LOOKBACK_DATE 设为周五的日期。这是周初简报。
   • 其他任何一天：回溯起始日期 = 昨天。将 LOOKBACK_DATE 设为昨天的日期。这是标准的每日简报。
   • 所有日期均使用 YYYY-MM-DD 格式。
2. 通过 ToolSearch（“slack”）、ToolSearch（“linear”）和 ToolSearch（“posthog”）检查可用集成
3. 检查 [CUSTOMIZE: path/to/meetings/] 中与 LOOKBACK_DATE 至今天日期范围匹配的会议记录
4. 检查 [CUSTOMIZE: path/to/braindumps/] 中与 LOOKBACK_DATE 至今天日期范围匹配的近期灵感记录

阶段 2：并行收集数据（同时启动 6 个 Agent）

使用 Task 工具并设置 run_in_background: true，在一条消息中启动所有这些 Agent：

Agent 1：“github-analyst”（subagent_type：general-purpose）

提示词：参见 references/agent-prompts.md § github-analyst。

Agent 2：“slack-monitor”（subagent_type：general-purpose）

仅在 Slack MCP 可用时启动 提示词：参见 references/agent-prompts.md § slack-monitor。

Agent 3：“meeting-reviewer”（subagent_type：general-purpose）

提示词：参见 references/agent-prompts.md § meeting-reviewer。

Agent 4：“linear-tracker”（subagent_type：general-purpose）

仅在 Linear MCP 可用时启动 提示词：参见 references/agent-prompts.md § linear-tracker。

Agent 5：“braindump-reviewer”（subagent_type：general-purpose）

提示词：参见 references/agent-prompts.md § braindump-reviewer。

Agent 6：“posthog-analyst”（subagent_type：general-purpose）

仅在 PostHog MCP 可用时启动 提示词：参见 references/agent-prompts.md § posthog-analyst。

第 3 阶段：汇总与交叉参照综合分析（协调者 — 所有 Agent 完成后）

这是最关键的阶段。协调者必须：

1. 收集结果：使用 Read 读取所有后台 Agent 的输出文件

2. 交叉参照 Linear ↔ GitHub（核心对齐检查）：

   • 根据标题、描述或明确引用，将 Linear issue 与对应的 PR/提交匹配起来
   • 标记状态为“In Progress”但没有对应 PR 或提交的 Linear issue（声称已开展但代码中尚未开始）
   • 标记没有对应 Linear issue 的 PR（未跟踪的工作——可能没有问题，只需注明）
   • 标记状态为“Done”但 PR 仍处于开放或未合并状态的 Linear issue（状态不匹配）
   • 注意 Linear 优先级与 PR 紧急程度不匹配的 issue（例如，Linear 中标记为 Urgent，但 PR 数天未获审核）

3. 交叉参照 Slack ↔ GitHub ↔ Linear：

   • 将 Slack 讨论主题与相关 PR/提交及 Linear issue 匹配起来
   • 将相关信息整合为统一条目（例如：“积分系统：[CUSTOMIZE: PROJ]-45 正在进行中 + Slack 中有 22 条相关回复 + PR #930 状态为 CHANGES_REQUESTED”）
   • 标记 Slack 讨论中提及但没有对应 PR、提交或 Linear issue 的工作
   • 标记 Slack 中未讨论过的 PR（未公开讨论的工作——可能没有问题，只需注明）

4. 交叉参照会议 ↔ GitHub ↔ Linear：

   • 检查昨天会议/站会中的行动项是否对应 PR、提交或 Linear issue
   • 标记已讨论但没有 GitHub 或 Linear 活动的变更
   • 记录已完成的行动项（已讨论、已交付且已跟踪）
   • 检查会议中分配的优先级是否与 Linear 优先级设置一致

5. 交叉参照脑力倾泻记录 ↔ 当前工作：

   • 将脑力倾泻记录中的战略思考与进行中的 Linear issue 和 GitHub PR 关联起来
   • 揭示脑力倾泻记录中提到但未体现在任何当前跟踪工作中的问题
   • 标记脑力倾泻记录中提及的方向变更是否与当前迭代优先级冲突

6. 交叉参照 Linear 周期 ↔ 整体进度：

   • 报告周期健康状况（完成百分比、剩余天数、进度节奏）
   • 标记范围是否正在扩大（周期中途新增 issue）
   • 突出显示阻碍周期完成的受阻事项

7. 交叉参照计划 ↔ 项目 ↔ Issue：

   • 对每项计划，汇总项目和 issue 数据，计算实际健康状况：
     • 统计所有关联项目中已完成和 issue 总数
     • 检查里程碑是否按计划进行或已逾期
     • 找出哪些项目正在推动进度，哪些项目陷入停滞
   • 标记计算得出的健康状况与报告健康状况不一致的计划
   • 标记临近目标日期但完成率较低的计划

8. 交叉参照 PostHog ↔ GitHub ↔ Slack：

   • 功能发布 ↔ 指标：将近期合并的 PR 与 PostHog 指标变化相关联。功能发布后使用量是否上升？还是发布后没有变化（采用问题）？
   • 错误激增 ↔ 部署：将 PostHog 错误激增与近期合并的 PR 匹配起来。如果特定合并后错误增多，应标记为潜在回归。
   • Slack 中的投诉 ↔ PostHog 数据：如果 Slack 讨论中提到用户问题，检查 PostHog 错误数据或漏斗流失是否印证了该问题。
   • 指标异常 ↔ 已知变更：如果访客数/注册量发生显著变化，应结合 GitHub 活动和 Slack 讨论进行交叉参照。
   • 功能采用情况 ↔ 计划目标：将 PostHog 功能使用数据与 Linear 计划 KPI 对应起来。标记其中的差距。
   • 激活漏斗 ↔ 入门引导工作：如果漏斗存在流失，检查是否有 PR 或 Linear issue 正在解决。若没有相关工作，应标记这一差距。

9. 按照下方的内容结构生成简报，先呈现洞察，最后呈现详情。遵循语气与风格指南——像团队成员一样写作，而不是像仪表板。

10. 保存到 [CUSTOMIZE: path/to/briefs/]daily-brief-YYYY-MM-DD.md，并填写正确的元数据

11. 向用户提供简明扼要的摘要

阶段 3.5：Linear 同步回写（协调器 — 交叉引用之后、Slack 之前）

此阶段会将数据写回 Linear，确保其内容与 GitHub、Slack 和会议中的实际情况保持同步。

使用 ToolSearch 加载必要的 Linear 更新工具："+linear update issue", "+linear update initiative", "+linear update project", "+linear create comment", "+linear create attachment", "+linear save status update", "+linear update milestone"。

步骤 1：PR ↔ Issue 关联

对于 GitHub 数据中发现的每个已合并或已打开的 PR：

1. 从 PR 标题、正文或分支中提取 Linear issue 引用（模式：[CUSTOMIZE: PROJ]-123）
2. 对于每个匹配的 Linear issue：
   • 使用 mcp__claude_ai_Linear__create_attachment 将 PR URL 附加到 issue（如果尚未关联）。使用以下格式：
     • url：https://github.com/[CUSTOMIZE: your-org/your-repo]/pull/XXX
     • title："PR #XXX: [PR title]"
   • 检查 issue 是否已附加此 PR（通过 get_issue 的 attachments）——如果已关联，则跳过以避免重复

步骤 2：根据 GitHub 同步 Issue 状态

根据阶段 3 的交叉引用数据：

1. PR 已合并 → Issue 仍处于“In Progress”：使用 mcp__claude_ai_Linear__update_issue 将 issue 转换为“Done”状态。添加评论："Automatically marked done — PR #XXX merged on [date]."
2. PR 已打开 → Issue 仍处于“Todo”/“Backlog”：使用 mcp__claude_ai_Linear__update_issue 将 issue 转换为“In Progress”。添加评论："Marked in progress — PR #XXX opened."
3. PR 的审查状态为 CHANGES_REQUESTED → Issue 标记为“In Review”：保留 issue 状态，但添加评论，说明审查反馈（如果尚未评论）。

安全规则：

• 仅自动转换 PR 与 issue 之间关联明确的状态（精确匹配 issue 前缀）
• 绝不将 issue 状态回退（例如，不要将“Done”改回“In Progress”）
• 如果多个 PR 引用了同一 issue，仅当所有相关 PR 均已合并时才标记为“Done”
• 记录每次状态变更，以便纳入简要摘要

步骤 3：更新 Initiative 状态

对于每个活跃的 initiative，使用 mcp__claude_ai_Linear__save_status_update 撰写并发布状态更新：

1. 从交叉引用中收集以下信息：
   • 回溯期开始以来已交付的内容（映射到此 initiative 项目的已合并 PR）
   • 此 initiative 各项目当前的阻碍因素
   • 此 initiative 各 issue 的周期进展
   • 与此 initiative 相关的关键 Slack 讨论
2. 撰写简洁的状态更新（3-5 个要点）：

   **[DATE] Daily Update**
   • Shipped: [list key PRs/features merged]
   • In Progress: [key items being worked on]
   • Blocked: [any blockers, or "None"]
   • Health: [On Track / At Risk / Off Track] — [1-line reasoning]
   • Next: [what's expected to ship next]
   

3. 使用 mcp__claude_ai_Linear__save_status_update 将更新发布到该 initiative
4. 如果数据明确表明 initiative 的健康状况已变化，使用 mcp__claude_ai_Linear__update_initiative 更新 health 字段

步骤 4：检查里程碑进度

对于活跃项目中的每个里程碑：

1. 统计里程碑中已完成和 issue 总数
2. 如果里程碑目标日期临近（≤7 天），且完成度 <70%，则标记
3. 如果里程碑已逾期（已过目标日期，且仍有未完成 issue），使用 mcp__claude_ai_Linear__update_milestone 更新其状态/描述并添加备注
4. 在 initiative 状态更新中包含里程碑健康状况

步骤 5：同步项目状态

对于每个活跃项目：

1. 如果项目中的所有 issue 均为“Done”，而项目状态仍为“In Progress”，则标记以更新状态
2. 如果项目中 >50% 的 issue 受阻，则在 initiative 状态更新中注明
3. 仅在状态发生重大变化时更新项目描述或摘要

同步回写摘要

完成所有同步回写操作后，汇总更新内容：

• 已同步状态的 issue：[count]（列出 issue ID 和新状态）
• 已关联的 PR：[count]（列出 PR#→issue 映射）
• 已发布的 initiative 更新：[count]
• 已标记的里程碑：[count]
• 同步过程中遇到的任何错误

在简报的“Linear 同步报告”部分中包含此摘要。

阶段 3.7：发布到 HackMD（Linear 同步回写之后、Slack 之前）

此阶段会将完整的每日简报发布到 HackMD，以便通过链接与团队分享。

HackMD API 令牌存储在 .claude/settings/hackmd-token 中（一行，不含空白字符）。使用以下命令读取：cat .claude/settings/hackmd-token | tr -d '\n'。或者检查环境变量 HACKMD_API_TOKEN。

API 详情：

• 基础 URL：https://api.hackmd.io/v1
• 身份验证标头：Authorization: Bearer <HACKMD_API_TOKEN>

步骤：

1. 通过 POST https://api.hackmd.io/v1/notes 创建笔记：

   {
     "title": "Daily Brief — [DAY_NAME], [FULL_DATE]",
     "readPermission": "signed_in",
     "writePermission": "owner",
     "commentPermission": "disabled",
     "content": "placeholder"
   }
   

   • readPermission: "signed_in" 表示任何拥有链接的 HackMD 用户都可以查看
   • 从响应中提取 id 和 publishLink

2. 通过 PATCH https://api.hackmd.io/v1/notes/<id> 更新笔记内容，写入完整的简报 Markdown 内容：

   • 从 [CUSTOMIZE: path/to/briefs/]daily-brief-YYYY-MM-DD.md 读取已保存的简报
   • 使用 Python 将内容编码为 JSON，并写入临时文件
   • 通过 curl -X PATCH ... -d @/tmp/hackmd-payload.json 发送

3. 保存 HackMD 链接，以便在 Slack 消息和本地简报文件中使用：

   • 第 1 步中的 publishLink（格式：https://hackmd.io/@[CUSTOMIZE: your-hackmd-username]/<shortId>）
   • 此链接会包含在 Slack 精选消息中
   • 将链接写回本地 .md 文件的 frontmatter，在 YAML frontmatter 中添加或更新 hackmd_url: <publishLink>。将其插入 created: 字段之后。使用 Edit 工具执行此操作——不要重写整个文件。

4. 如果 HackMD API 失败，记录错误并继续——仍应将简报发布到 Slack，但不附带链接。在 Slack 消息中注明：“（HackMD 链接不可用）”

**实现模式（Bash）：**参见 references/publish-templates.md § HackMD implementation pattern (Bash)。

阶段 4：Slack 精选摘要（简报保存后 — 发布前预览）

向用户展示简报摘要后，务必撰写并展示 Slack 精选消息供其预览。显示用户将在 Slack 中看到的确切消息，然后询问：“准备将此消息发布到 #[CUSTOMIZE: your-team-channel] 吗？（或者先编辑内容）”

**在用户明确确认之前，不要发布。**如果用户提出修改，请调整内容并展示更新后的预览。只有在用户表示同意／确认／看起来不错／发送吧等之后，才能发布。

1. 撰写符合 Slack 风格的精选消息 — 不是完整简报，只包含团队最需要了解的要点。内容要简短，让大家愿意读完。

2. 用户确认后，使用 ToolSearch 加载 Slack 发送工具，然后通过 mcp__claude_ai_Slack__slack_send_message 将消息发布到 [CUSTOMIZE: your-team-channel] 频道。

3. Slack 消息格式（根据实际内容调整 — 以下是模板，并非固定格式）：

**星期一（每周开始简报）：**完整模板见 references/publish-templates.md § Slack 消息格式 — 星期一（每周开始简报）。

**普通日：**完整模板见 references/publish-templates.md § Slack 消息格式 — 普通日。

4. Slack 消息规则：
   • 星期一简报最多 30 行，普通日最多 20 行。比以往内容更详细，但仍须便于浏览。
   • 先讲积极进展（已交付的内容），再讲问题。
   • 只包含今天确实需要团队关注的提醒。
   • 不要直接贴出原始 PR 表格，但要列出已合并的 PR，并用一行说明其内容，让大家知道具体改了什么。
   • 总结 Slack 上的重要讨论 — 团队经常会错过讨论串。用 2–3 句话回顾重要对话，能带来实际价值。
   • 列出待办事项及负责人，让大家知道各自需要做什么。
   • 使用通俗语言，不要使用项目管理术语。写“还没人审查 #930”，而不是“REVIEW_REQUIRED 状态仍然存在”。
   • 如果没有紧急事项，就简短说明：“今天进展顺利，已交付 X，没有紧急问题。”
   • 仅在有益时提及具体人员（例如祝贺某项成果，或对方明确负责后续事项时）。不要公开点名批评未能按时完成任务的人。
   • **务必为 PR 引用嵌入 GitHub 链接。**使用 Slack 链接格式：<https://github.com/[CUSTOMIZE: your-org/your-repo]/pull/XXX|#XXX>。不要只写 #930 — 要确保链接可点击。
   • 务必在 Slack 消息末尾添加 HackMD 链接，格式为 :link: *完整简报：* [HACKMD_URL]。团队将通过此链接查看完整详细简报。

阶段耗时

• 阶段 1：约 10 秒
• 阶段 2：约 60–90 秒（全部 6 个 Agent 并行运行）
• 阶段 3：约 45 秒（6 路交叉核对并汇总，包括 PostHog ↔ GitHub 关联分析）
• 阶段 3.5：约 30–45 秒（同步回写 Linear — PR 关联、状态同步、计划更新）
• 阶段 3.7：约 10 秒（发布到 HackMD — 创建私密笔记，上传完整简报内容）
• 阶段 4：约 10 秒（用户确认后发布 Slack 消息并附上 HackMD 链接）
• 总计：约 3–4 分钟（如需发布 Slack 消息，耗时另计）

---

内容结构（优先级顺序 — 重要内容在前，详细信息在后）

1. 开场（1–2 句话）

快速判断当天的整体情况。交付进展是否顺利？是否比较平静？讨论很多但没有合并？用通俗语言交代背景。

**如果是星期一（每周开始简报）：**围绕周末情况展开，并为新的一周定下基调。示例：“周一快乐 — 团队周末也很忙，合并了 6 个 PR。下面是周五以来的进展，以及本周的计划。”

普通日示例：

进展顺利 — v1.2.0 已发布，合并了 11 个 PR。团队正在快速推进新功能。不过，入职引导方面的问题正在加剧，需要及时处理，以免失去更多潜在客户。

2. 需要注意的事项（重点提醒）

今天需要关注的事项。最多列出 3–5 项。写成队友在每日站会上会提醒的事项，而不是系统警报。

类型（按优先级排序）：

• 计划健康状况恶化（计划从「按计划进行」变为「有风险」，或里程碑逾期）
• 进度停滞的受阻／紧急 Linear 问题
• 长时间未处理的 PR（已打开超过 3 天且未获评审，或处于 CHANGES_REQUESTED 状态超过 2 天）
• Linear ↔ GitHub 状态不一致（例如，Linear 标记为“已完成”，但 PR 仍处于打开状态）
• 临近截止日期但完成度较低的里程碑（剩余 ≤7 天，完成度 <70%）
• 缺少后续跟进（会议／Slack 中讨论过，但 GitHub／Linear 中没有相关动态）
• 评审积压（超过 5 个 PR 等待评审）
• 周期健康警告（进度落后、范围膨胀）
• 约定与实际行动不一致
• Slack 中尚未解决的阻碍
• 严重错误或问题
• 未关联 Linear 问题的 PR（未跟踪的工作）
• 与近期部署相关的 PostHog 错误激增（可能是回归问题）
• 重要指标大幅下降（访客数、注册数下降超过 20%）
• 漏斗流失，但没有对应的 Linear 问题（未跟踪的产品缺口）

示例：

注册流程出问题了 — 两位潜在客户在连续两次探索性通话中都卡在注册环节。目前这两个问题都没有修复 PR。

评审积压越来越严重 — 有 22 个 PR 处于打开状态，其中 16 个已长期未处理。有些已超过 100 天。我们应该快速梳理一下，关闭那些已经不再需要的 PR。

API 文档（#930） 需要先解决评审者的反馈，才能合并实现（#933）。不要在不确定的基础上继续开发。

3. 关键洞察（综合分析、交叉关联）

整合 Slack、GitHub 和会议中的信息。将相关事项归在一起。这里要充分发挥交叉关联的作用——将讨论过的内容与代码中的实际进展联系起来。

4. 已交付内容

庆祝取得的成果。简要总结已合并的 PR。如果可以，按主题归类，而不只是逐项罗列。

5. 正在进行的工作

列出已打开的 PR、评审状态以及对应的 Linear 问题状态。标注等待时长和任何看起来停滞的事项。展示 Linear 状态与 PR 实际状态是否一致。

6. 计划健康状况仪表板

针对每项进行中的计划，展示简明状态：

格式：

计划名称 — 健康状况：按计划进行 | 完成度 23% | 剩余 76 天

• 项目：项目 A（进行中，40%）、项目 B（进行中，15%）
• 里程碑：里程碑 1（截止日期为 3 月 15 日 — 按计划进行）、里程碑 2（截止日期为 3 月 30 日 — 有风险）
• 今日交付：PR #945（功能 X）、PR #948（功能 Y）
• 阻碍：无

7. 周期与冲刺健康状况

当前 Linear 周期进度——完成百分比、剩余天数、范围变更。如果团队进度正常或落后，请明确指出。

8. 团队概览

简要展示速度指标——无需面面俱到，只需足以了解团队状态。包含 GitHub 指标（PR、提交）和 Linear 指标（已完成的问题、周期进度）。

9. 产品指标（来自 PostHog）

快速了解产品基于真实用户数据的实际表现。这能让工程活动立足于业务现实。

格式：

访客： 342（↑12%，较前一日） | 注册： 8（↓25%） | 核心事件： 156（↑34%） | 错误： 新增 3 个

数据说明： 发布循环检测修复（PR #942）后，核心事件大幅增加——用户在工作流中能继续深入，而不会遇到错误。注册量有所下降，但可能只是因为今天比较平静。

功能采用情况： 23 位独立用户使用了 new-feature（早期表现良好）。onboarding-flow 在电子邮件验证步骤仍有 40% 的流失率。

错误监控： 自昨天部署以来，/api/execute 新增 3 个 TypeError 错误。与合并 PR #935 相关。

规则：

• 仅在有 PostHog 数据时包含本节
• 始终显示趋势方向（↑ ↓ →）和变化百分比
• 尽可能将指标变化与已发布的 PR 关联起来
• 标记错误激增，并将其与近期部署关联起来
• 最多 4-6 行——详细分析应单独呈现

10. Linear 同步报告

每日简报同步回写到 Linear 的内容摘要：

• 已同步事项：X 个事项的状态已更新（列出事项 ID 和新状态）
• 已关联 PR：X 个 PR 已关联到 Linear 事项（列出对应关系）
• 已发布计划更新：X 个计划收到状态更新
• 已标记里程碑：X 个里程碑有风险或已逾期
• 错误：任何同步失败（或“全部正常”）

11. 战略背景（来自 Braindumps）

近期 braindumps 中与当前工作相关的关键见解。这能让简报不止于“发生了什么”，还补充产品负责人的思考，说明“为何重要”。

12. 昨日讨论（参考）

详细的 Slack 讨论摘要。此处为附录——想了解详情的人可以阅读。

13. 会议后续跟踪

将近期会议的行动项与实际的 GitHub/Slack/Linear 活动进行跟踪。使用状态指示符，让进展一目了然。

---

元数据模板

已保存简报文件的完整 YAML frontmatter 模板：references/brief-frontmatter.md。

综合规则

交叉引用逻辑

1. Linear 事项 + 对应的 PR → 在 Linear 中将它们关联起来（阶段 3.5）。标记状态不一致的情况（例如，Linear 显示“已完成”，但 PR 仍处于打开状态）
2. Linear 事项处于“In Progress”状态 + 没有 PR/提交 → 标记为“声称已开始，但尚无代码”（可能只是刚开始，但超过 1 天就值得注意）
3. 存在 PR + 没有 Linear 事项 → 记录为未跟踪的工作。这不一定是问题，但今后应在 Linear 中跟踪
4. Slack 话题提及 PR 编号或 Linear 事项 → 在关键洞察中将它们关联起来
5. Slack 中讨论某项功能 + 存在 PR 和/或 Linear 事项 → 综合这三类信号，形成统一洞察
6. 会议行动项 + 没有匹配的 PR/提交，也没有 Linear 事项 → 标记为缺少后续跟进（没有任何地方跟踪）
7. 会议行动项 + 存在 Linear 事项，但没有 PR → 已跟踪但尚未开始——注明状态
8. Slack 中达成的共识 + GitHub/Linear 活动与之矛盾 → 标记为不一致
9. 多个 Slack 话题讨论同一主题 → 整合为一条洞察
10. 头脑风暴记录提及某项功能/方向 + Linear/GitHub 中存在相关工作 → 将战略思考与执行工作关联起来
11. 头脑风暴记录提出某项担忧 + 没有 Linear 事项或 PR 在处理该问题 → 标记为“战略缺口——已有相关思考，但没有跟踪中的工作”
12. Linear 中紧急/高优先级事项 + 近期没有活动（>2 天） → 标记为关键工作停滞
13. PR 已合并 + Linear 事项仍处于打开状态 → 在阶段 3.5 自动将状态改为“已完成”，并在同步报告中注明
14. PR 已打开 + Linear 事项处于“Todo”状态 → 在阶段 3.5 自动将状态改为“In Progress”
15. 计划日期临近 + 项目完成度较低 → 将计划健康状况标记为“有风险”，并在 Linear 中更新
16. 里程碑已逾期 + 事项尚未完成 → 标记该里程碑，并在 Linear 中更新
17. 已完成的工作对应某计划中的项目 → 在发布到 Linear 的计划状态更新中纳入该工作
18. PR 已合并 + PostHog 指标激增 → 分析两者的关联——该功能可能促成了变化。在“已发布内容”中附上影响数据
19. PR 已合并 + PostHog 错误激增 → 在“提醒”中标记为潜在回归问题，并附上错误详情和 PR 链接
20. PostHog 注册/核心事件数据下降 + 没有明显原因 → 在产品指标中标记为异常。检查这是否是周末/节假日规律，还是实际问题
21. PostHog 功能采用率低 + 相关计划的目标是增长 → 标记构建内容与用户实际使用情况之间的差距
22. PostHog 漏斗流失 + 没有 Linear 事项在处理该问题 → 标记为未跟踪的产品缺口——用户遇到困难，但没有人在处理
23. Slack 用户投诉 + PostHog 错误数据证实 → 提高优先级——数据已证实用户确实受到影响

过期 PR 规则

• 超过 3 天且处于 REVIEW_REQUIRED 状态 → 标记为过期
• 超过 2 天且处于 CHANGES_REQUESTED 状态，同时没有新提交 → 标记为过期
• 超过 5 天，无论状态如何 → 标记为长期挂起
• 在提醒中附上链接和负责人

计划健康状况规则

• 按计划推进：达到预期进度的 ≥60%（已完成事项数量相对于已过时间与目标日期的比例），且没有关键阻碍
• 有风险：达到预期进度的 40–60%，或存在 ≥2 个受阻事项，或里程碑已逾期
• 偏离计划：达到预期进度的 <40%，或多个项目中存在 ≥3 个受阻事项，或多个里程碑已逾期
• 健康状况评估使用真实数据（事项数量、里程碑日期），而不只是报告的状态

优先级排序

存在多个提醒时，按以下顺序排列：

1. 倡议健康状况恶化（倡议转为“有风险”或“偏离轨道”）
2. 阻塞项（Linear 中被阻塞的问题，或其他无法推进的事项）
3. PostHog 错误激增，且与近期部署相关（可能是回归问题——用户现在正受到影响）
4. 里程碑逾期或有风险（有时效性，会影响倡议健康状况）
5. Linear ↔ GitHub 不一致（两个系统之间的状态偏差）
6. 指标显著下降（访客数、注册数下降超过 20%——可能表明存在实际问题）
7. 停滞或长期未处理的 PR（有时效性，情况正在恶化）
8. 缺少后续跟进（承诺未兑现——既没有 Linear 问题，也没有 PR）
9. 周期健康预警（进度落后、范围蔓延）
10. 审查瓶颈（拖慢团队速度）
11. 战略缺口（脑暴记录中提出的问题没有对应的跟踪工作）
12. 漏斗流失但没有对应的跟踪工作（产品缺口）
13. 信息性不一致（了解即可）

---

回退行为

• Slack 不可用：跳过 Slack 部分，仅运行 GitHub、Linear 和会议部分。注明：slack: unavailable
• Linear 不可用：跳过 Linear 部分，运行 GitHub、Slack 和会议部分。注明：linear: unavailable。对此进行标记——Linear 现已是主要工作跟踪工具
• PostHog 不可用：跳过产品指标部分，运行其他 Agent。注明：posthog: unavailable。即使没有这部分，简报仍然有用。
• 未找到会议：跳过会议后续跟进部分，继续处理其他来源
• 未找到脑暴记录：跳过战略背景部分——这是可选补充内容，并非关键内容
• GitHub 不可用（罕见）：注明错误，跳过开发活动

错误处理

• 如果 gh CLI 命令失败，报告错误并跳过该数据点
• 如果 Linear MCP 工具失败，报告错误并注明失败的查询。即使批量查询失败，也要尝试单独执行各项查询
• 如果 Slack MCP 响应缓慢，设置合理的超时时间，并在没有 Slack 数据的情况下继续
• 如果未找到昨天的会议文件，则回退检查前天的文件
• 如果未找到脑暴文件，则静默跳过——脑暴记录是按需撰写的，并非每天都有
• Linear 同步回写错误：如果回写操作失败，在同步报告中记录错误，但不要频繁重试——继续执行其余同步操作。即使部分同步回写步骤失败，也应生成简报。
• 避免重复：在问题上创建附件（PR 链接）之前，检查现有附件以避免重复。在发布倡议状态更新之前，检查当天是否已发布过，以避免刷屏。
• 状态转换安全性：绝不要自动将问题转换到会导致信息丢失的状态。如果不确定某次转换是否安全，请在同步报告中将其记录为“建议”，而不要执行。