email-to-issue

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Email to issue

邮件转 Issue

One run is a sweep: read the chosen Outlook threads, propose one table for all of them, and file only the rows the user approves, by

issue-tracker

. New issues stop at

Backlog

; triage routes them and writes any agent brief.

Find the Microsoft 365 connector's mail tools by capability — read, search, reply, move, flag — since their names change between connector versions.

一次运行即为一轮批量处理：读取选定的 Outlook 邮件会话，为所有会话拟定一张统一表格，并依据

issue-tracker

仅为用户批准的行创建 issues。新建 issues 会停留在

Backlog

；triage 会对它们进行路由，并编写所需的 agent brief。

按能力查找 Microsoft 365 connector 的邮件工具——读取、搜索、回复、移动和标记——因为这些名称会随 connector 版本而变化。

Mail permissions

邮件权限

Every mail action in the sweep falls inside this list. For anything else, tell the user it is theirs to do by hand.

Allowed:
- Read and search mail.
- Send the reply in a thread filed this sweep.
- Clear the flag on, and move to Archive, a thread filed this sweep, once the user confirms in step 6.
Never:
- Delete mail, drafts included.
- Send, forward or draft mail to anyone but the signed-in user.
- Write to calendar, files or Teams.

本轮批量处理中的每项邮件操作都必须在以下列表内。对于其他操作，告诉用户需要手动完成。

允许：
- 读取和搜索邮件。
- 为本轮批量处理中已创建 issue 的邮件会话发送回复。
- 在用户于步骤 6确认后，清除已创建 issue 的邮件会话上的旗标，并将其移动到
```
Archive
```
  。
绝不允许：
- 删除任何邮件，包括草稿。
- 向已登录用户之外的任何人发送、转发邮件，或为其起草邮件。
- 写入日历、文件或 Teams。

The sweep

批量处理流程

1. Gather

1. 收集

Read every flagged Inbox thread, or the threads the user names by subject. When a subject matches several threads, list them with sender and date and ask which.

Skip a thread that already holds the reply: it is processed. Leave attachments in the mail, and note on the row that the thread has one.

Done when: a list of threads to process, each with sender, date and subject, plus a count of those skipped as processed.

读取所有已加旗标的 Inbox 邮件会话，或用户按主题指定的邮件会话。当一个主题匹配多个会话时，列出发件人和日期，并询问用户选择哪一个。

如果某个邮件会话中已有回复，则跳过该会话：它已被处理。不要从邮件中移除附件，并在对应行注明该会话带有附件。

**完成标准：**一份待处理邮件会话列表，每项包含发件人、日期和主题，并给出因已处理而跳过的数量。

2. Check permissions

2. 检查权限

Writing to mail needs two capabilities:

Reply, taking its recipients as an argument. A reply that only pre-fills the sender does not count.
Move and flag: move to Archive and clear a flag.

Without them, the sweep still files issues and step 6 ends in a manual list.

Done when: the user has one line saying whether this sweep can reply, and whether it can unflag and archive.

向邮件写入需要具备两项能力：

回复，且能够将收件人作为参数传入。仅预填发件人的回复不算。
移动和旗标：移动到
```
Archive
```
并清除旗标。

如果没有这些能力，本轮批量处理仍会创建 issues，而步骤 6将以一份手动处理清单结束。

**完成标准：**用一行告知用户，本轮批量处理是否能够回复，以及是否能够取消旗标并归档。

3. Match

3. 匹配

Search open issues across the org for one that already covers each thread:

bash

gh search issues "<key terms>" --owner clhbid --state open --json repository,number,title,url

Try two or three phrasings, and read a candidate before calling it a match. A match becomes a comment carrying only what the thread adds — new evidence or a clarification. No match becomes a new issue in the repo the thread is about.

Done when: every thread has a proposed action and target.

在整个组织中搜索 open issues，找出每个邮件会话是否已有对应条目：

bash

gh search issues "<key terms>" --owner clhbid --state open --json repository,number,title,url

尝试两到三种不同的检索措辞，并在判定匹配前阅读候选 issue。匹配成功时，创建一条 comment，其中只包含邮件会话新增的信息——新证据或澄清。没有匹配时，则在与该邮件会话相关的 repo 中创建 new issue。

**完成标准：**每个邮件会话都有一个拟执行的操作和目标。

4. Propose

4. 提议

Read each target's visibility, then draft its title by Confidentiality:

bash

gh repo view clhbid/<repo> --json visibility --jq .visibility

Show one table for the whole sweep:

#	Source	Action	Target	Visibility	Title	Label
1	Pat Example ( `pat@example.com` ), 2 Mar	New issue	`clhbid/<repo>`	PRIVATE	Bid export drops the last lot	`bug`
2	Sam Sample ( `sam@example.org` ), 3 Mar	Comment	`clhbid/<repo>#123`	PUBLIC	Second report of the timeout	—

The user approves, edits or skips each row. GitHub stays untouched until then.

Done when: every row is approved or skipped.

读取每个目标的可见性，然后按照保密性要求拟定标题：

bash

gh repo view clhbid/<repo> --json visibility --jq .visibility

为整轮批量处理展示一张表：

#	来源	操作	目标	可见性	标题	标签
1	Pat Example ( `pat@example.com` )，3 月 2 日	新建 issue	`clhbid/<repo>`	PRIVATE	Bid 导出丢失最后一批	`bug`
2	Sam Sample ( `sam@example.org` )，3 月 3 日	评论	`clhbid/<repo>#123`	PUBLIC	第二次出现 timeout	—

用户可以批准、编辑或跳过每一行。在此之前，GitHub 不会发生任何更改。

**完成标准：**每一行均已批准或跳过。

5. File

5. 提交

For each approved row, write by Confidentiality:

New issue: by
```
issue-tracker
```
§ Creating an issue from the org form
, then confirm it landed in
```
Backlog
```
.

Comment:

gh issue comment <number> --repo clhbid/<repo>

, as a

writing-lean

thread comment.

Done when: every approved row has a link, and every new issue reads back as

Backlog

对于每一行已批准的内容，按照保密性要求撰写：

新建 issue：按照
```
issue-tracker
```
§ 从组织表单创建 issue
操作，然后确认该 issue 已进入
```
Backlog
```
。

评论：

gh issue comment <number> --repo clhbid/<repo>

，以

writing-lean

邮件会话评论的形式撰写。

**完成标准：**每一行已批准的内容都有链接，且每个新建 issue 回读时均显示为

Backlog

。

6. Close the loop

6. 收尾

Send the reply in each filed thread. Then list the filed threads and ask which to unflag and archive; approving the table in step 4 is not that confirmation. Move only the threads the user confirms.

Without write tools, list each filed thread with sender, date, subject and issue link, for the user to reply, unflag and archive by hand. The reply is what lets the next sweep skip the thread.

Done when: a sweep summary gives each thread's issue link and outcome — replied, unflagged, archived, or left to the user, with the reason for every skipped reply.

在每个已创建 issue 的邮件会话中发送回复。然后列出这些会话，询问用户要取消哪些会话的旗标并归档；批准步骤 4 的表格并不代表该确认。只移动用户明确确认的会话。

如果没有写入工具，列出每个已创建 issue 的邮件会话及其发件人、日期、主题和 issue 链接，供用户手动回复、取消旗标和归档。发送回复后，下一轮批量处理才能跳过该会话。

**完成标准：**一份批量处理摘要，列出每个会话的 issue 链接和处理结果——已回复、已取消旗标、已归档，或留给用户处理——并说明每个跳过回复的原因。

The reply

It marks a thread processed and links it to its issue.

Take the user's address from the connector's signed-in profile. Ask when it is missing or ambiguous.

Write the body, marker first:

text

Filed by /email-to-issue: clhbid/<repo>#<number>
https://github.com/clhbid/<repo>/issues/<number>

Replace the recipients:
```
To
```
the user alone,
```
Cc
```
and
```
Bcc
```
empty.
Read every recipient field back from the built message. Send only when the user is the one recipient.
On any doubt, skip the reply and put the link in the sweep summary. Name any draft left behind so the user can remove it.

回复用于标记邮件会话已处理，并将其链接到对应 issue。

从 connector 的已登录用户配置文件中获取用户地址。缺失或有歧义时询问用户。

编写正文，并将标记放在最前面：

text

Filed by /email-to-issue: clhbid/<repo>#<number>
https://github.com/clhbid/<repo>/issues/<number>

替换收件人：
```
To
```
仅填用户，
```
Cc
```
和
```
Bcc
```
留空。
从已构建的消息中回读每个收件人字段。只有当用户是唯一收件人时才发送。
有任何疑虑时，跳过回复，并把链接放入批量处理摘要。如果留下了草稿，要明确注明，以便用户删除。

Confidentiality

保密性

Titles, bodies and comments follow the target's visibility:

PRIVATE
: the thread's details in full, confidential ones included.
PUBLIC
: a paraphrase. Name the sender by role ("a seller", "a bidder"), and leave out customer names, contact details, pricing and other proprietary detail.
Anything else, or unsure about a detail: ask.

标题、正文和评论必须遵循目标的可见性：

PRIVATE
：可完整写入邮件会话的详细信息，包括机密内容。
PUBLIC
：必须转述。按角色称呼发件人（“一名卖家”“一名竞标者”），不要包含客户姓名、联系方式、价格或其他专有信息。
其他情况，或对任何细节不确定时：询问用户。