关于 email-to-issue
用于将选定的 Outlook 邮件线程整理为 GitHub 问题操作提案，并且只提交用户批准的条目。流程包括匹配未关闭问题、按可见性起草内容，以及受控的回复和归档步骤。
主要功能
- 01收集已标记或指定的 Outlook 邮件
- 02将邮件匹配到未关闭的 GitHub 问题
- 03在一张审批表中列出全部操作
- 04提交获批的问题或评论
- 05通过权限检查后回复和归档
适用场景
- 01将已标记邮件转为 GitHub 问题
- 02为现有问题补充新证据
- 03提交前审阅邮件转问题提案
- 04完成已提交邮件线程的后续处理
MCP 相关
该技能按能力使用 Microsoft 365 连接器的邮件工具，包括读取、搜索、回复、移动和标记；未指定 MCP 服务。
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/email-to-issue确认已加载。
详细介绍
邮件转 issue
一次运行称为一次归档整理：读取选定的 Outlook 邮件线程，为所有线程拟定一张表格，并且只通过 issue-tracker 创建用户批准的行。新建 issue 保持在 Backlog；由分诊人员确定流转方向并撰写任何 Agent 简报。
按功能查找 Microsoft 365 连接器的邮件工具——读取、搜索、回复、移动、标记——因为它们的名称会随连接器版本变化。
邮件权限
归档整理中的所有邮件操作都在以下列表范围内。其他任何操作都应告知用户由其手动完成。
- 允许：
- 绝不允许：
- 删除邮件，包括草稿。
- 向已登录用户以外的任何人发送、转发或起草邮件。
- 写入日历、文件或 Teams。
归档整理
1. 收集
读取所有已标记的收件箱线程，或用户按主题指定的线程。如果某个主题匹配多个线程，列出发件人和日期并询问用户要处理哪一个。
跳过已有回复的线程：这类线程视为已处理。附件保留在邮件中，并在对应行注明该线程含有附件。
**完成条件：**列出要处理的线程，包括每个线程的发件人、日期和主题，并统计跳过的已处理线程数量。
2. 检查权限
写入邮件需要两项能力：
- 回复：将收件人作为参数传入。仅预先填入发件人的回复功能不符合要求。
- 移动和标记：移至 Archive 并清除标记。
如果没有这些能力，仍可创建 issue，但步骤 6将以手动操作清单结束。
**完成条件：**用户收到一行说明，明确本次归档整理是否可以回复，以及是否可以取消标记并归档。
3. 匹配
在整个组织中搜索未关闭的 issue，查找已涵盖每个邮件线程的 issue：
gh search issues "<key terms>" --owner clhbid --state open --json repository,number,title,url
尝试两到三种表述方式，并在判定匹配前阅读候选 issue。匹配时添加一条评论，只记录该线程带来的新内容——新证据或澄清。没有匹配项时，在邮件线程所涉的仓库中创建一个新 issue。
**完成条件：**每个线程都有拟议的操作和目标。
4. 提议
查看每个目标的可见性，然后按照保密性起草标题：
gh repo view clhbid/<repo> --json visibility --jq .visibility
为本次归档整理的所有线程展示一张表格：
| # | 来源 | 操作 | 目标 | 可见性 | 标题 | 类型 |
|---|---|---|---|---|---|---|
| 1 | Pat Example（[email protected]），2 Mar | 新建 issue | clhbid/<repo> | PRIVATE | 投标导出会漏掉最后一个标段 | Bug |
| 2 | Sam Sample（[email protected]），3 Mar | 评论 | clhbid/<repo>#123 | PUBLIC | 超时问题的第二次报告 | — |
用户可以批准、编辑或跳过每一行。在此之前，不会对 GitHub 作任何更改。
**完成条件：**每一行都已获批准或跳过。
5. 提交
对每一条获批准的行，按照保密性进行操作：
- 新建 issue：使用
issue-tracker§ 从组织表单创建 issue， 然后确认其已进入Backlog。 - 评论：执行
gh issue comment <number> --repo clhbid/<repo>，作为writing-lean线程评论。
**完成条件：**每一条获批准的行都有链接，并且每个新 issue 回读后都显示为 Backlog。
6. 完成闭环
在每个已归档的会话中发送回复。然后列出已归档的会话，并询问用户要取消标记并归档哪些会话；第 4 步中批准表格不等于确认。只处理用户确认的会话。
没有写入工具时，列出每个已归档会话的发件人、日期、主题和问题链接，由用户手动回复、取消标记并归档。回复可让下一轮检查跳过该会话。
完成标准： 检查摘要为每个会话提供问题链接和处理结果——已回复、已取消标记、已归档或留给用户处理，并说明每条跳过的回复的原因。
回复
它会标记会话已处理，并将其关联到对应问题。
-
从连接器已登录的个人资料中获取用户的地址。若缺失或不明确，请询问。
-
撰写正文，将标记放在开头：
Filed by /email-to-issue: clhbid/<repo>#<number> https://github.com/clhbid/<repo>/issues/<number> -
替换收件人：
To仅填写用户，Cc和Bcc留空。 -
逐一复核已生成邮件中的每个收件人字段。只有当用户是唯一收件人时才发送。
-
有任何疑虑时，跳过回复，并将链接放入检查摘要。注明留下的任何草稿，以便用户删除。
保密性
标题、正文和评论应遵循目标的可见性：
PRIVATE：完整提供会话详情，包括机密信息。PUBLIC：改述内容。按角色称呼发件人（“一位卖家”“一位竞标者”），并省略客户姓名、联系方式、价格和其他专有细节。- 其他任何情况，或对某项细节拿不准时：请询问。