用途：把选定的 Outlook 邮件线程批量整理成 GitHub issue 或评论。一次运行即一次 sweep：读取被标记的收件箱线程或用户按主题指定的线程，为所有线程提出一张表格，只提交用户批准的行。新 issue 停在 Backlog，后续由分类流程处理并撰写 agent brief。
主要能力与流程：先收集线程（含发件人、日期、主题，并列出已处理而跳过的数量），再检查权限。写邮件需两种能力：能以收件人为参数回复，以及移动和标记（归档并清除标记）。缺少时仍可归档 issue，但第 6 步改为人工清单。随后用 gh search issues 搜索组织内已有 issue 进行匹配，尝试两三种措辞并阅读候选后再判定；匹配则只补充线程新增信息作为评论，不匹配则在相关仓库新建 issue。提案阶段读取目标仓库可见性，按机密性拟定标题：PRIVATE 用线程完整细节，PUBLIC 用改述、以角色称发件人并省略客户名、联系方式、价格等专有信息，不确定则询问。用户逐行批准、编辑或跳过后才写入 GitHub。
必要用法：通过能力（而非名称）查找 Microsoft 365 连接器的邮件工具；使用 gh repo view clhbid/<repo> --json visibility --jq .visibility 读取可见性，使用 gh issue comment <number> --repo clhbid/<repo> 写评论。回复正文需以标记开头，标明 issue 链接，收件人只保留登录用户本人，Cc 与 Bcc 留空，并回读每个收件人字段确认后才发送。
适用场景：需要将 Outlook 邮件反馈、缺陷报告整理进 GitHub 追踪并保持机密级别一致的工作流。
限制：禁止删除邮件（含草稿）、禁止向登录用户以外的人发送、转发或起草邮件、禁止写日历、文件或 Teams；仅允许读取搜索邮件、在本次归档线程中回复、经用户确认后清除标记并移至 Archive。任何其他操作须告知用户手动完成。如无写邮件工具，则列出每条线程的发件人、日期、主题与 issue 链接供手动处理。未提供安装步骤与具体价格等信息。