邮件操作
当实际任务为邮箱工作时使用：分类、起草、回复、发送，或确认邮件已进入已发送文件夹。
这不是通用写作技能，而是围绕实际邮件界面的操作工作流。
技能栈
在相关场景下调用这些ECC原生技能：
brand-voice在起草任何面向用户的内容之前investor-outreach用于面向投资者、合作伙伴或赞助商的邮件customer-billing-ops当邮件线程属于账单/支持事件而非普通通信时knowledge-ops当需要将消息或线程捕获到持久上下文中时research-ops当回复依赖最新外部事实时
使用时机
- 用户要求分类收件箱或清理低价值邮件
- 用户需要起草、回复或发送新邮件
- 用户想确认邮件是否已发送
- 用户需要验证使用的账户、线程或已发送记录
安全护栏
- 除非用户明确要求实时发送，否则先起草
- 未经真实已发送文件夹或客户端确认，不得声称邮件已发送
- 不随意切换发件账户；选择与项目和收件人匹配的账户
- 清理时不删除不确定的业务邮件
- 若任务实为私信或iMessage工作，转交至
messages-ops
工作流程
1. 确认具体界面
操作前明确：
- 哪个邮箱账户
- 哪个线程或收件人
- 任务是分类、起草、回复还是发送
- 用户需要仅起草还是实时发送
2. 撰写前阅读线程
若回复：
- 阅读现有线程
- 识别最后一次对外联系
- 识别任何承诺、截止日期或未回答问题
若创建新外发邮件：
- 确定亲密度等级
- 选择正确渠道和发件账户
- 起草前调用
brand-voice
3. 起草，然后验证
仅起草任务：
- 生成最终副本
- 说明发件人、收件人、主题和目的
实时发送任务：
- 先验证最终正文
- 通过选定邮件界面发送
- 确认消息已进入已发送文件夹或等效的已发送副本存储
4. 报告确切状态
使用精确状态词：
- 已起草
- 待审批
- 已发送
- 被阻止
- 等待验证
若发送界面被阻止，保留草稿并报告确切阻止原因，而非未经说明即改用第二传输方式。
输出格式
常见陷阱
- 未经已发送副本检查不得声称发送成功
- 不得忽略线程历史而撰写无上下文的回复
- 不得混淆邮箱工作与私信或短信工作流
- 不得泄露机密、认证详情或不必要的消息元数据
验证
- 回复中指明账户和线程或收件人
- 任何发送声明均包含已发送证明或明确的客户端确认
- 最终状态为：已起草/已发送/被阻止/等待验证
