inbox-triage

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Inbox-Triage — Recurring Email Triage

Inbox-Triage — 定期邮件分类整理

Paired with
inbox-setup
. This skill consumes the 7-file knowledge base that
inbox-setup
writes at
${WORKSPACE}/Email/
. The file contracts MUST match exactly. See
references/kb_file_contract.md
— this is the mirror of the setup-side contract, viewed from the read side.

Run on a recurring schedule (1–3x daily) or on demand. Classify recent emails, research new senders, generate decision recommendations, draft replies (NEVER SEND), deliver a clean report, and update the knowledge base with what was learned this run.

与
inbox-setup
配套使用。本Skill会读取
inbox-setup
写入
${WORKSPACE}/Email/
目录下的7文件知识库。文件格式必须完全匹配。请参阅
references/kb_file_contract.md
— 这是从读取视角出发的设置端格式规范镜像。

支持按定期计划（每日1–3次）或按需运行。对近期邮件进行分类、研究新发件人、生成决策建议、撰写回复草稿（绝不发送）、生成清晰报告，并将本次运行的学习成果更新到知识库中。

Invocation Triggers

触发指令

"triage my inbox"
"inbox triage"
"check my email"
"run email triage"
"process my inbox"
"what's new in my email"
"handle my email"
"email triage"

"triage my inbox"
"inbox triage"
"check my email"
"run email triage"
"process my inbox"
"what's new in my email"
"handle my email"
"email triage"

Prerequisites

前置条件

Required reads at start (fail-fast if missing):

Core (required):

```
${WORKSPACE}/Email/email-taxonomy.md
```
— classification + report preferences
```
${WORKSPACE}/Email/email-patterns.md
```
— voice, persona, templates, hard rules

Optional core (read if exists):

${WORKSPACE}/Email/evaluation-framework.md

```
${WORKSPACE}/Email/rate-card.md
```

Evolving (read AND update every run):

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

Output:

${WORKSPACE}/Email/triage-log/<YYYY-MM-DD>-<run-label>.md

— per-run log

If any core required file is missing → halt, direct user to run

inbox-setup

first. Use

scripts/kb_reader.py

to perform the read + validation.

启动时需要读取以下文件（若缺失则立即终止）：

核心必填文件：

```
${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

执行读取与验证操作。

DRAFTS ONLY — Never Send

仅生成草稿 — 绝不发送

This skill creates drafts. It NEVER sends.

This is the safety property that makes the skill safe to run automatically. Stated multiple times in this skill body. Non-negotiable.

The

scripts/draft_safety_validator.py

enforces it post-run. Any send-shaped tool call in the action log fails validation. See

references/drafts_only_safety.md

for the full discipline canon.

本Skill仅创建草稿，绝不发送邮件。

这是确保Skill可安全自动运行的核心安全特性。在Skill文档中多次强调，不可妥协。

scripts/draft_safety_validator.py

会在运行后强制执行此规则。若操作日志中存在任何发送类工具调用，验证将失败。完整规范请参阅

references/drafts_only_safety.md

。

Step 0: Grill-Me Intake (Light — 0–2 Optional Override Questions)

步骤0：轻量交互（0–2个可选覆盖问题）

Inbox-triage is light-intake by design — it runs on a recurring cadence with preferences pre-baked into the knowledge base from

inbox-setup

. The grill-me discipline here is asking ONLY the override questions that matter THIS run.

Inbox-triage设计为轻量交互模式 — 它按定期频率运行，使用

inbox-setup

中预配置的知识库偏好设置。此处的交互仅询问与本次运行相关的覆盖问题。

Q1 (optional, asked only when on-demand run is outside normal cadence)

问题1（可选，仅当按需运行超出常规频率时询问）

Override the default 9-hour search window? Pick: yes (specify hours) / no (use default).

Why I'm asking: If you're running on-demand outside your normal 2x/day cadence, you may want a wider window (24h after a long break) or narrower (2h for a quick check).

Skip if cadence is normal.

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

询问原因： 若你在常规每日2次的频率之外按需运行，可能需要更宽的窗口（长时间休息后设为24小时）或更窄的窗口（快速检查设为2小时）。

若运行频率符合常规则跳过此问题。

Q2 (optional, asked only when user invokes with category-skip intent)

问题2（可选，仅当用户调用时包含跳过分类的意图时询问）

Skip any categories this run? E.g., "skip newsletters", "skip financial".

Why I'm asking: Sometimes you just want to scan opportunities or just want to clear active threads. Category skip narrows the run scope.

Skip if user gave no category-skip signal.

Stop condition: Max 2 questions. Default invocations skip both questions and run with KB-default preferences. The skill is optimized for fast recurring execution; intake is the exception, not the norm.

本次运行是否跳过某些分类？例如："跳过新闻通讯"、"跳过财务类邮件"。

询问原因： 有时你只想查看机会类邮件，或只想清理活跃线程。跳过分类可缩小运行范围。

若用户未发出跳过分类的信号则跳过此问题。

停止条件： 最多询问2个问题。默认调用会跳过这两个问题，使用知识库默认偏好设置。Skill优化为快速定期执行，交互仅为特殊情况，非常规操作。

Step 1: Determine Search Window

步骤1：确定搜索窗口

Compute via current date math. Default lookback: 9 hours (works for 2x/day cadence with slight overlap so emails between runs aren't missed).

Use

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"

Cadence-to-default-window mapping (override via Q1):

Cadence (from email-taxonomy.md S1.Q5)	Default window
once daily	26h
2x daily	9h
3x daily	6h
on-demand only	24h (asks Q1)

通过当前日期计算。默认回溯时长：9小时（适用于每日2次的频率，略有重叠以避免遗漏两次运行之间的邮件）。

使用

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

：

now = current_datetime
window_start = now - 9_hours   (默认每日2次频率)
run_label = "Morning" if now.hour < 12 else "Afternoon" if now.hour < 17 else "Evening"

频率与默认窗口的对应关系（可通过问题1覆盖）：

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

Step 2: Email Search

步骤2：邮件搜索

Two queries (provider-agnostic adapter pattern):

Primary: Inbox + sent after
```
window_start
```
Secondary: Starred unread (catch flagged items missed in primary)

Collect for each email: sender, subject, date, snippet, thread ID, labels.

Provider adapter mapping:

Provider	Tool
Gmail	Gmail MCP
Outlook / Microsoft 365	Outlook MCP
IMAP (Fastmail, ProtonMail, etc.)	IMAP MCP if available; halt otherwise
(no email tool available)	Halt with clear message: "No email tool registered for this session."

两个查询（采用与服务商无关的适配器模式）：

主查询： 收件箱 +
```
window_start
```
之后发送的邮件
副查询： 已加星标的未读邮件（捕捉主查询中遗漏的标记项）

收集每封邮件的信息：发件人、主题、日期、摘要、线程ID、标签。

服务商适配器映射：

服务商	工具
Gmail	Gmail MCP
Outlook / Microsoft 365	Outlook MCP
IMAP（Fastmail、ProtonMail等）	若有IMAP MCP则使用；否则终止运行
（无可用邮件工具）	终止运行并显示清晰提示："本次会话未注册邮件工具。"

Step 3: Classification

步骤3：分类

Apply the taxonomy from

email-taxonomy.md

. For lowest-priority category (newsletters / automation / spam): skip thread reads entirely — context cost not worth it. For everything else: read full thread.

应用

email-taxonomy.md

中的分类规则。对于最低优先级的分类（新闻通讯/自动化邮件/垃圾邮件）：完全跳过线程读取 — 不值得花费上下文成本。其他分类则读取完整线程。

Step 4: Sender Research

步骤4：发件人研究

For senders not in tracker / blocklist / prior logs:

Check
```
blocklist.md
```
→ if matched, auto-skip
Check
```
tracker.md
```
→ if known thread, note existing context
For opportunity senders (per evaluation framework): web search for company legitimacy, social presence, intermediary status

Skip research entirely for: known senders (in tracker), internal email, automated notifications, obvious low-priority.

对于未出现在追踪列表/黑名单/过往日志中的发件人：

检查
```
blocklist.md
```
→ 若匹配则自动跳过
检查
```
tracker.md
```
→ 若为已知线程则记录现有上下文
对于机会类发件人（根据评估框架）：通过网络搜索验证公司合法性、社交存在、中介身份

完全跳过研究的情况： 已知发件人（在追踪列表中）、内部邮件、自动化通知、明显低优先级邮件。

Step 5: Recommendations

步骤5：处理建议

For decision-required emails, apply the framework from

evaluation-framework.md

. Categorize:

Category	When	Output
TAKE IT	Meets criteria	Recommend engaging; draft reply (Step 6)
WORTH CONSIDERING	Has potential, needs user judgment	Surface key context; draft for user to edit
PASS	Doesn't meet criteria	Brief "why" (1–3 sentences); draft polite decline
FLAG FOR REVIEW	Unusual; needs direct user decision	Surface fully; NO draft (user decides response shape)

Each: brief "why", relevant context, pricing/timeline comparison if applicable.

Skip Step 5 entirely if no
evaluation-framework.md
exists.

See

references/triage_decision_framework.md

for the framework canon.

对于需要决策的邮件，应用

evaluation-framework.md

中的框架。分类如下：

分类	适用场景	输出
接受	符合标准	建议跟进；撰写回复草稿（步骤6）
值得考虑	有潜力，需用户判断	呈现关键上下文；生成草稿供用户编辑
拒绝	不符合标准	简短说明原因（1–3句话）；撰写礼貌的拒绝草稿
标记待审核	异常情况；需用户直接决策	完整呈现内容；不生成草稿（由用户决定回复形式）

每个建议包含：简短说明原因、相关上下文、适用的价格/时间对比（若有）。

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

完整框架规范请参阅

references/triage_decision_framework.md

。

Step 6: Drafts

步骤6：生成草稿

For every reasonable reply candidate, create a draft using

email-patterns.md

voice rules.

Draft for: opportunity responses (TAKE IT / WORTH / PASS), active conversations needing reply, action items, important personal emails.

Do NOT draft for:

Clearly no-response emails (newsletters, automation, FYI)
Threads where user already replied
Blocked senders (unless new info changes the calculus)

Mechanics:

Draft only in the existing thread when possible (preserves context)
Set
```
to
```
,
```
subject
```
(
```
Re: [original]
```
)
NEVER call any send operation. Only create drafts.

The draft body MUST honor:

Voice register from
```
email-patterns.md
```
Forbidden tokens (S3.Q2 pet peeves)
Sign-off patterns
Persona context
Hard rules (S3.Q6 — non-negotiable)
Reply length per
```
email-patterns.md
```

evaluation-framework.md

exists, draft tone matches recommendation:

TAKE IT → engaged + concrete next step
WORTH → curious + 1-2 clarifying questions
PASS → polite decline + brief reason (no hedging promises)
FLAG → NO draft

对于所有合理的回复候选，使用

email-patterns.md

中的语气规则创建草稿。

需要生成草稿的场景： 机会类邮件回复（接受/值得考虑/拒绝）、需要回复的活跃对话、行动项、重要个人邮件。

无需生成草稿的场景：

明确无需回复的邮件（新闻通讯、自动化邮件、仅供参考邮件）
用户已回复的线程
黑名单中的发件人（除非新信息改变判断）

执行机制：

尽可能在现有线程中生成草稿（保留上下文）
设置
```
to
```
、
```
subject
```
（
```
Re: [原主题]
```
）
绝不调用任何发送操作，仅创建草稿。

草稿内容必须遵循：

```
email-patterns.md
```
中的语气风格
禁用词汇（S3.Q2中的反感内容）
签名格式
角色设定上下文
硬性规则（S3.Q6 — 不可妥协）
```
email-patterns.md
```
中规定的回复长度

若

evaluation-framework.md

存在，草稿语气需匹配建议类型：

接受 → 积极参与 + 具体下一步行动
值得考虑 → 好奇 + 1-2个澄清问题
拒绝 → 礼貌拒绝 + 简短原因（不做模糊承诺）
标记待审核 → 不生成草稿

Step 7: Report Delivery

步骤7：报告交付

Honor user's preference from

email-taxonomy.md

"Report Preferences" section. Default: email draft to self with HTML.

Subject:

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

Sections (in order):

Overview — 2–3 sentences. What happened? Anything urgent?
Stats — Counts: processed, drafts created, action needed, skipped.
Action Needed — Overdue items, decisions, drafts to review, deadlines.
Quick Reference — One line per email, alphabetical by sender.
```
**Sender** — one-sentence summary + recommendation
```
.
Detailed Cards — Opportunities, active threads, flags. Each: sender / subject / category, recommendation + reasoning, key context. NO draft text previews (drafts are already in email client for user to read there).
Footer — Generation timestamp + KB update summary.

Formatting (if HTML):

Inline CSS only (Gmail strips
```
<style>
```
)
Color-coded by recommendation:
- green → TAKE IT
- amber → WORTH CONSIDERING
- red → PASS
- purple → FLAG FOR REVIEW
- blue → active conversation

遵循

email-taxonomy.md

中"报告偏好"部分的用户设置。默认：生成发送给自己的HTML格式邮件草稿。

主题：

Inbox Triage — [星期], [月 日] ([运行标签])

报告章节（按顺序）：

概述 — 2–3句话。本次运行处理了什么？是否有紧急事项？
统计数据 — 处理数量、生成草稿数量、需处理事项数量、跳过数量。
待处理事项 — 逾期项、待决策项、待审核草稿、截止日期。
快速参考 — 按发件人字母排序，每封邮件一行。
```
**发件人** — 一句话摘要 + 处理建议
```
。
详细卡片 — 机会类邮件、活跃线程、标记项。每项包含：发件人/主题/分类、建议及理由、关键上下文。不包含草稿内容预览（草稿已在邮件客户端中，用户可直接查看）。
页脚 — 生成时间戳 + 知识库更新摘要。

HTML格式要求：

仅使用内联CSS（Gmail会移除
```
<style>
```
标签）
按建议类型进行颜色编码：
- 绿色 → 接受
- 黄色 → 值得考虑
- 红色 → 拒绝
- 紫色 → 标记待审核
- 蓝色 → 活跃对话

Step 8: Knowledge Base Update

步骤8：更新知识库

blocklist.md
(append new):

New declined senders + reason + date
New decline patterns from observed behavior (e.g., "all emails containing 'looking for backend engineers' from gmail addresses → cold recruiter pattern")
Remove entries if user has overridden them (user replied to a "blocked" sender → unblock)

tracker.md
(append + update):

New follow-ups for emails needing future action
Update existing follow-ups (deadline changed, status changed)
Mark resolved items complete
Flag overdue items
Remove resolved items older than 30 days
Add entry to update log

Learning patterns to observe over runs:

Drafts sent as-is vs. edited vs. deleted → tone calibration signal
PASS recommendations user overrides → framework adjustment signal
Engaged vs. ignored emails → taxonomy refinement signal
New decline patterns → blocklist additions

After 5+ runs, suggest KB improvements to user (e.g., "You always decline emails from X — add as auto-skip?").

blocklist.md
（追加新内容）：

新增拒绝的发件人 + 原因 + 日期
新增从行为中观察到的拒绝模式（例如："所有来自Gmail地址且包含'寻找后端工程师'的邮件 → 冷招聘模式"）
若用户已覆盖黑名单设置（用户回复了黑名单中的发件人）则移除对应条目

tracker.md
（追加并更新内容）：

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

需在多次运行中观察的学习模式：

草稿直接发送/编辑后发送/删除 → 语气校准信号
用户覆盖拒绝建议 → 框架调整信号
用户跟进/忽略的邮件 → 分类体系优化信号
新的拒绝模式 → 黑名单新增项

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

Step 9: Internal Log

步骤9：内部日志

Save to

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

Emails processed with classifications
Recommendations made
Drafts created (with IDs / thread refs)
KB updates made
Follow-ups added / resolved
Notable observations (patterns surfaced, edge cases handled)

The log is the audit trail for

scripts/draft_safety_validator.py

to scan for send operations post-run.

保存至

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

：

已处理邮件及其分类
生成的建议
创建的草稿（包含ID/线程引用）
知识库更新内容
添加/完成的跟进项
值得注意的观察（发现的模式、处理的边缘情况）

该日志是

scripts/draft_safety_validator.py

在运行后扫描发送操作的审计线索。

Step 10: Empty Inbox Handling

步骤10：空收件箱处理

Even with zero new emails:

Check
```
tracker.md
```
for items due today or overdue
Generate minimal report: "No new actionable emails since last run"
Flag any overdue items
Escalate per tracker rules

Skip Steps 3–6 entirely on empty inbox.

即使没有新邮件：

检查
```
tracker.md
```
中今日到期或逾期的项
生成极简报告："自上次运行以来无新的可操作邮件"
标记任何逾期项
根据追踪列表规则升级处理

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

Critical Rules (Stated Multiple Times)

关键规则（多次强调）

DRAFTS ONLY — NEVER SEND. Non-negotiable. Stated again here.
Privacy. No passwords / credentials in KB. Reference threads by ID for sensitive content.
Accuracy over speed. When unsure, flag for review. A wrong auto-draft is worse than no draft.
Respect the KB. Documented preferences are source of truth. Don't override with judgment.
Transparency. Note every KB change in the triage log.
First runs need oversight. Document this expectation for the user.

仅生成草稿 — 绝不发送。 不可妥协。在此再次强调。
隐私保护。 知识库中不得包含密码/凭据。敏感内容通过线程ID引用。
准确性优先于速度。 不确定时标记待审核。错误的自动草稿比没有草稿更糟。
遵循知识库。 文档化的偏好是唯一依据。不得用自身判断覆盖。
透明度。 在分类整理日志中记录每一项知识库变更。
首次运行需监督。 向用户明确此预期。

Error Handling

错误处理

Situation	Behavior
KB files missing	Halt; direct user to run `inbox-setup`
Email tool unavailable	Halt with clear message about required tool
Web search unavailable for sender research	Skip research step; note senders not researched
Draft creation fails	Skip that draft; note in log; report continues
Report delivery fails	Save report to file as fallback; notify user
User has 100+ new emails	Stay within reasonable limits; flag volume; offer to focus on priority categories only
Sender appears in both blocklist and tracker	Tracker wins (active conversation); note inconsistency in log

场景	行为
知识库文件缺失	终止运行；引导用户运行 `inbox-setup`
邮件工具不可用	终止运行并显示清晰的工具缺失提示
发件人研究无网络搜索可用	跳过研究步骤；记录未研究的发件人
草稿创建失败	跳过该草稿；在日志中记录；报告继续生成
报告交付失败	将报告保存为文件作为备选；通知用户
用户有100+封新邮件	保持合理处理范围；标记邮件数量；仅处理优先分类
发件人同时出现在黑名单和追踪列表中	追踪列表优先（活跃对话）；在日志中记录不一致情况

Portability

可移植性

Claude Code CLI: Native — uses Gmail / Outlook MCP, file tools for KB, web search for research.
Claude.ai web: Works when email MCP connector is connected (Gmail MCP available). Skill must check tool availability before assuming. If no email tool: halt with clear message.

Claude Code CLI： 原生支持 — 使用Gmail/Outlook MCP、文件工具处理知识库、网络搜索进行发件人研究。
Claude.ai网页版： 连接邮件MCP连接器（已支持Gmail MCP）时可使用。Skill在运行前必须检查工具可用性。若无邮件工具则终止运行并显示清晰提示。

Tooling

工具集

Script	Role
`scripts/kb_reader.py`	Reads + validates the 7-file KB. Returns parsed structure. Halts with explicit error if required files missing.
`scripts/search_window_calculator.py`	Computes `window_start` from cadence + current time. Returns `run_label` . Honors Q1 override.
`scripts/draft_safety_validator.py`	Post-run scan of the action log for any send-shaped tool call. FAILs if detected. The deterministic enforcement of the NEVER-SEND rule.

脚本	作用
`scripts/kb_reader.py`	读取并验证7文件知识库。返回解析后的结构。若必填文件缺失则明确报错并终止。
`scripts/search_window_calculator.py`	根据频率和当前时间计算 `window_start` 。返回 `run_label` 。遵循问题1的覆盖设置。
`scripts/draft_safety_validator.py`	运行后扫描操作日志中的任何发送类工具调用。若检测到则验证失败。这是"绝不发送"规则的确定性强制执行机制。

References

参考文档

references/kb_file_contract.md

— canonical 7-file contract (read perspective; mirrors

inbox-setup/references/kb_file_contract.md

)

```
references/triage_decision_framework.md
```
— TAKE IT / WORTH / PASS / FLAG taxonomy
```
references/drafts_only_safety.md
```
— the NEVER-SEND discipline canon

references/kb_file_contract.md

— 标准7文件格式规范（读取视角；与

inbox-setup/references/kb_file_contract.md

对应）

```
references/triage_decision_framework.md
```
— 接受/值得考虑/拒绝/标记待审核分类体系
```
references/drafts_only_safety.md
```
— "绝不发送"规则的完整规范

Anti-Patterns To Reject

需避免的反模式

Sending emails (drafts only — non-negotiable)
Operating without knowledge base files
Storing passwords / credentials in KB
Skipping the learning loop (KB updates) at end of run
Overriding user's documented preferences with own judgment
Reading lowest-priority threads (waste of context)
Including draft text previews in report (drafts are already in email client)
Provider lock-in without adapter pattern
Silently failing on missing tools

Version: 1.0.0 Source spec:

megaprompts/07-inbox-triage-megaprompt.md

Build pattern: Path B (direct conversion). Paired with

inbox-setup

发送邮件（仅生成草稿 — 不可妥协）
在无知识库文件的情况下运行
在知识库中存储密码/凭据
运行结束时跳过学习循环（知识库更新）
用自身判断覆盖用户的文档化偏好
读取最低优先级线程（浪费上下文）
在报告中包含草稿内容预览（草稿已在邮件客户端中）
未采用适配器模式导致服务商锁定
工具缺失时静默失败

版本： 1.0.0 来源规范：

megaprompts/07-inbox-triage-megaprompt.md

构建模式： 路径B（直接转换）。与

inbox-setup

配套使用。