inbox-triage

Inbox-Triage — 定期电子邮件分流

与 inbox-setup 配套使用。 此技能使用 inbox-setup 写入 ${WORKSPACE}/Email/ 的 7 个文件的知识库。文件契约必须完全一致。请参阅 references/kb_file_contract.md——这是从读取端查看的 setup 端契约副本。

按固定计划（每天 1–3 次）或按需运行。对近期邮件进行分类，调查新发件人，生成决策建议，起草回复（绝不发送），提供清晰的报告，并根据本次运行的收获更新知识库。

调用触发条件

• “整理我的收件箱”
• “收件箱分流”
• “查收我的电子邮件”
• “运行电子邮件分流”
• “处理我的收件箱”
• “我的电子邮件有什么新内容”
• “处理我的电子邮件”
• “电子邮件分流”

前提条件

开始时必须读取以下文件（缺失时快速失败）：

核心（必需）：

• ${WORKSPACE}/Email/email-taxonomy.md — 分类和报告偏好
• ${WORKSPACE}/Email/email-patterns.md — 语气、身份设定、模板和硬性规则

可选核心文件（存在时读取）：

• ${WORKSPACE}/Email/evaluation-framework.md
• ${WORKSPACE}/Email/rate-card.md

持续更新（每次运行都要读取并更新）：

• ${WORKSPACE}/Email/blocklist.md
• ${WORKSPACE}/Email/tracker.md

输出：

• ${WORKSPACE}/Email/triage-log/<YYYY-MM-DD>-<run-label>.md — 每次运行的日志

如果缺少任何必需的核心文件 → 停止，并指引用户先运行 inbox-setup。使用 scripts/kb_reader.py 执行读取和验证。

仅创建草稿——绝不发送

此技能只会创建草稿，绝不会发送。

这是让此技能能够安全自动运行的安全属性。本技能正文中会多次重申。此规则不可妥协。

scripts/draft_safety_validator.py 会在运行后强制执行该规则。操作日志中任何类似发送的工具调用都会导致验证失败。完整规则请参阅 references/drafts_only_safety.md。

步骤 0：需求确认（简要——0–2 个可选覆盖问题）

Inbox-triage 有意采用简要需求确认——它按固定频率运行，偏好已由 inbox-setup 预先写入知识库。此处的需求确认只询问本次运行真正重要的覆盖问题。

Q1（可选，仅在按需运行且不在正常频率范围内时询问）

要覆盖默认的 9 小时搜索窗口吗？请选择：是（指定小时数）/ 否（使用默认值）。

询问原因： 如果你在正常的每日 2 次运行计划之外按需运行，可能希望采用更长的窗口（长时间间隔后使用 24 小时）或更短的窗口（快速查看时使用 2 小时）。

频率正常时跳过。

Q2（可选，仅在用户调用时表示要跳过某些类别时询问）

本次运行要跳过哪些类别吗？例如：“跳过新闻邮件”“跳过财务邮件”。

询问原因： 有时你可能只想查看机会，或只想处理活跃对话。跳过类别可缩小运行范围。

用户未表示要跳过类别时跳过。

停止条件： 最多询问 2 个问题。默认调用会跳过两个问题，并使用知识库中的默认偏好。此技能针对快速定期运行进行了优化；需求确认是例外，而非惯例。

步骤 1：确定搜索窗口

根据当前日期计算。默认回溯时长：9 小时（适用于每日 2 次的运行频率，并稍有重叠，以免漏掉两次运行间收到的邮件）。

使用 scripts/search_window_calculator.py --cadence <CADENCE> --now <ISO>：

now = current_datetime
window_start = now - 9_hours   (default for 2x-daily)
run_label = "Morning" if now.hour < 12 else "Afternoon" if now.hour < 17 else "Evening"

频率与默认搜索窗口的对应关系（可通过 Q1 覆盖）：

频率（来自 email-taxonomy.md S1.Q5）	默认窗口
每日一次	26h
每日 2 次	9h
每日 3 次	6h
仅按需运行	24h（询问 Q1）

步骤 2：搜索邮件

使用两个查询（与提供商无关的适配器模式）：

• 主要查询： 收件箱 + window_start 之后的已发送邮件
• 次要查询： 已加星标的未读邮件（捕获主要查询中遗漏的标记邮件）

收集每封邮件的以下信息：发件人、主题、日期、摘要、会话 ID、标签。

提供商适配器映射：

提供商	工具
Gmail	Gmail MCP
Outlook / Microsoft 365	Outlook MCP
IMAP（Fastmail、ProtonMail 等）	如果有 IMAP MCP，则使用；否则停止
（没有可用的邮件工具）	停止并显示明确消息："No email tool registered for this session."

步骤 3：分类

应用 email-taxonomy.md 中的分类体系。对于优先级最低的类别（新闻邮件 / 自动邮件 / 垃圾邮件）：完全跳过会话读取——上下文成本不值得。其他所有邮件：读取完整会话。

步骤 4：发件人调查

对于不在跟踪器 / 阻止名单 / 先前日志中的发件人：

1. 检查 blocklist.md → 如果匹配，则自动跳过
2. 检查 tracker.md → 如果是已知会话，则记录现有上下文
3. 对于机会发件人（根据评估框架）：通过网络搜索确认公司真实性、社交媒体影响力及是否为中间商

完全跳过调查的情况：已知发件人（在跟踪器中）、内部邮件、自动通知、明显的低优先级邮件。

步骤 5：建议

对于需要决策的邮件，应用 evaluation-framework.md 中的框架。分类如下：

类别	适用情况	输出
接受	符合标准	建议参与；起草回复（步骤 6）
值得考虑	有潜力，需要用户判断	提供关键背景；起草供用户编辑的回复
拒绝	不符合标准	简要说明“原因”（1–3 句话）；起草礼貌的拒绝回复
标记待审阅	情况特殊；需要用户直接决定	完整呈现；不提供草稿（由用户决定回复方式）

每项建议都应包含简要的“原因”、相关背景，以及适用时的价格 / 时间安排对比。

如果不存在 evaluation-framework.md，则完全跳过步骤 5。

框架规范请参阅 references/triage_decision_framework.md。

步骤 6：草稿

对于每个合理的回复候选项，使用 email-patterns.md 中的语气规则创建草稿。

起草回复的对象： 机会类邮件回复（接受 / 值得考虑 / 拒绝）、需要回复的活跃对话、待办事项、重要的私人邮件。

不要起草回复：

• 明显无需回复的邮件（新闻邮件、自动邮件、供参考邮件）
• 用户已回复的会话
• 已屏蔽发件人的邮件（除非新信息改变了判断）

操作细则：

• 尽可能仅在现有会话中起草（保留上下文）
• 设置 to、subject（Re: [original]）
• 绝不要调用任何发送操作。只能创建草稿。

草稿正文必须遵循：

• email-patterns.md 中的语气风格
• 禁用词语（S3.Q2 中列出的雷区）
• 结尾格式
• 人设背景
• 硬性规则（S3.Q6 — 不可妥协）
• email-patterns.md 中的回复长度要求

如果存在 evaluation-framework.md，草稿语气应与建议一致：

• 接受 → 积极回应 + 明确的下一步
• 值得考虑 → 表达兴趣 + 1–2 个澄清问题
• 拒绝 → 礼貌拒绝 + 简要说明原因（不做含糊承诺）
• 标记待审阅 → 不起草回复

步骤 7：报告交付

遵循用户在 email-taxonomy.md 的“报告偏好”部分中的偏好。默认：以 HTML 格式将邮件草稿发送给自己。

主题： Inbox Triage — [Day], [Month Date] ([Run Label])

章节（按顺序）：

1. 概览 — 2–3 句话。发生了什么？有什么紧急事项吗？
2. 统计 — 数量：已处理、已创建草稿、需要采取行动、已跳过。
3. 需要采取行动 — 逾期事项、待决事项、待审核草稿、截止日期。
4. 快速参考 — 每封邮件一行，按发件人字母顺序排列。**Sender** — one-sentence summary + recommendation。
5. 详细卡片 — 机会、进行中的对话、标记事项。每项包括：发件人 / 主题 / 类别、建议及理由、关键信息。不要预览草稿文本（草稿已在邮件客户端中，供用户查看）。
6. 页脚 — 生成时间戳 + 知识库更新摘要。

格式（HTML）：

• 仅使用内联 CSS（Gmail 会移除 <style>）
• 按建议使用颜色标记：
  • 绿色 → 接受
  • 琥珀色 → 值得考虑
  • 红色 → 拒绝
  • 紫色 → 标记以供审核
  • 蓝色 → 正在进行的对话

步骤 8：知识库更新

blocklist.md（追加新条目）：

• 新增拒绝的发件人 + 原因 + 日期
• 根据观察到的行为新增拒绝模式（例如，“所有来自 gmail 地址、包含 'looking for backend engineers' 的邮件 → 冷启动招聘者模式”）
• 如果用户覆盖了相关规则，则移除条目（用户回复了某个“已屏蔽”发件人的邮件 → 解除屏蔽）

tracker.md（追加 + 更新）：

• 为需要后续处理的邮件添加新的待跟进事项
• 更新现有待跟进事项（截止日期变更、状态变更）
• 将已解决事项标记为完成
• 标记逾期事项
• 移除超过 30 天的已解决事项
• 在更新日志中添加条目

多次运行时需要观察的学习模式：

• 草稿原样发送、经过编辑或被删除 → 语气校准信号
• 用户覆盖“拒绝”建议 → 框架调整信号
• 用户回复或忽略的邮件 → 分类体系优化信号
• 新的拒绝模式 → 添加到屏蔽列表

运行 5 次以上后，向用户建议改进知识库（例如，“你总是拒绝来自 X 的邮件——要将其添加为自动跳过项吗？”）。

步骤 9：内部日志

保存到 ${WORKSPACE}/Email/triage-log/[YYYY-MM-DD]-[run-label].md：

• 已处理邮件及其分类
• 提出的建议
• 已创建的草稿（含 ID / 线程引用）
• 已进行的知识库更新
• 已添加 / 已解决的待跟进事项
• 值得注意的观察（发现的模式、处理的边缘情况）

该日志是审计记录，供 scripts/draft_safety_validator.py 在运行后扫描发送操作。

步骤 10：空收件箱处理

即使没有新邮件：

1. 检查 tracker.md 中今天到期或已逾期的事项
2. 生成简要报告：“自上次运行以来没有新的可操作邮件”
3. 标记任何逾期事项
4. 按照跟踪器规则升级处理

收件箱为空时，完全跳过步骤 3–6。

关键规则（多次重申）

1. 仅创建草稿——绝不发送。 不容妥协。在此再次重申。
2. 隐私。 知识库中不得包含密码 / 凭据。敏感内容的线程请通过 ID 引用。
3. 准确优先于速度。 不确定时，标记以供审核。错误的自动草稿比不创建草稿更糟。
4. 遵循知识库。 已记录的偏好是事实依据。不要凭主观判断覆盖。
5. 透明。 在分类日志中记录每一项知识库变更。
6. 首次运行需要监督。 将此预期告知用户。

错误处理

情况	行为
缺少 KB 文件	停止；引导用户运行 inbox-setup
电子邮件工具不可用	停止，并明确说明所需的工具
无法通过网页搜索调查发件人	跳过调查步骤；注明尚未调查发件人
创建草稿失败	跳过该草稿；在日志中注明；继续生成报告
报告发送失败	将报告保存到文件作为备用方案；通知用户
用户有 100 封以上新邮件	控制在合理范围内；标记邮件数量；提出仅处理优先类别
发件人同时出现在屏蔽名单和跟踪名单中	以跟踪名单为准（活跃对话）；在日志中注明不一致

可移植性

• Claude Code CLI： 原生支持 — 使用 Gmail / Outlook MCP、用于 KB 的文件工具，以及用于调查的网页搜索。
• Claude.ai 网页版： 连接电子邮件 MCP 连接器后即可使用（可用 Gmail MCP）。Skill 必须先检查工具是否可用，不能想当然地认为工具可用。如果没有电子邮件工具：停止并明确说明。

工具

脚本	用途
scripts/kb_reader.py	读取并验证 7 个 KB 文件。返回解析后的结构。缺少必需文件时会停止，并明确报错。
scripts/search_window_calculator.py	根据频率和当前时间计算 window_start。返回 run_label。遵循 Q1 覆盖规则。
scripts/draft_safety_validator.py	运行后扫描操作日志，检查是否有任何发送类工具调用。检测到时会失败。这是对“绝不发送”规则的确定性强制措施。

参考资料

• references/kb_file_contract.md — 规范的 7 个文件约定（读取视角；与 ../inbox-setup/references/kb_file_contract.md 内容一致）
• references/triage_decision_framework.md — TAKE IT / WORTH / PASS / FLAG 分类体系
• references/drafts_only_safety.md — “只创建草稿，绝不发送”规范

应避免的反模式

• 发送电子邮件（仅创建草稿 — 不容妥协）
• 在没有知识库文件的情况下操作
• 在 KB 中存储密码 / 凭据
• 在运行结束时跳过学习循环（更新 KB）
• 用自己的判断覆盖用户记录在案的偏好
• 阅读优先级最低的邮件主题（浪费上下文）
• 在报告中包含草稿文本预览（草稿已在电子邮件客户端中）
• 未采用适配器模式，导致被某个服务提供商锁定
• 工具缺失时不作说明，静默失败

---

版本： 1.0.0 源规范： megaprompts/07-inbox-triage-megaprompt.md（维护者本地草稿规范 — 已加入 gitignore，未包含在公开仓库中） 构建模式： Path B（直接转换）。与 inbox-setup 配套。