ingest

/ingest — 原始人工输入 → 结构化工作

你是一个中继中心：客户端给你发消息，合作伙伴给你发邮件，通话会被转录。每种内容都包含决策、行动项、Bug 和事实——而手动处理每一条，都意味着要一遍遍重新解释同一套流程。这个技能就是把这套流程记录下来。

约定： 内部、可撤销的输出（知识库记录、归档的议题）直接完成，不必走过场。面向外部的输出（回复）始终只起草，绝不发送。

文件

路径	内容
${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ingest/people.yaml	人员 → 项目/仓库/知识库页面/回复渠道的路由映射（私有，已加入 gitignore）
<vault>/raw/call-<slug>.md / <vault>/raw/message-<slug>.md	按 second-brain 的架构保存的记录
references/people.yaml.example	配置架构及完整示例

<vault> 是 ${SECOND_BRAIN_VAULT:-$HOME/Documents/SecondBrain}。

步骤 0 — 获取输入并分类

按以下顺序获取：提示词中的内容 → 剪贴板（macOS 上使用 pbpaste，Linux 上使用 wl-paste / xclip -o；没有剪贴板的 Agent 则跳过）→ 询问。

根据内容形式分类，而不是根据用户的称呼：

形式	类型
说话人标签和时间戳，或 Grain/Zoom/Granola/Fathom URL 或标题	通话
“from X:” / 转发文本或私信，第一人称，简短	消息
邮件标头，或包含称呼/落款的结构	邮件（按正式语气处理为消息）
无结构的第一人称叙述（“好吧，我在想……”）	语音备忘录（不起草回复；仅记录内容和行动项）

长篇转录有时会在聊天中被截断——如果内容明显在句中断开，请说明情况并索要文件（或路径），不要处理残缺片段。

步骤 1 — 确认人员和项目

读取 people.yaml。根据 name 和 aliases 匹配参与者/发件人。

• 匹配成功 → 现在已知仓库、知识库页面、回复渠道和语气备注。用一行说明所用路由（“路由：Jane → acme-app”）。
• 未匹配 → 只询问一次：“这是谁？属于哪个项目？”然后询问是否将其添加到 people.yaml，避免今后重复询问。如果用户拒绝添加，则使用明确指定的目标处理输入，而不是采用默认路由。
• 一次通话涉及多个项目（合作伙伴通话中很常见）→ 按项目拆分提取内容；分别路由各部分。

步骤 2 — 提取

先通读全部输入。然后提取以下内容，并为每项附上简短的原文引述或释义作为依据：

1. 已作出的决策 — 已确定的事项，包括“我们不做 X”。
2. 行动项 — 我方 — 用户欠他人的事项。注明已给出的截止日期。
3. 行动项 — 对方 — 他人欠用户的事项（这些内容应放入回复的后续跟进部分，而不是创建为议题）。
4. Bug 和功能请求 — 应转为 GitHub 议题的内容。每项单独建一个议题，切勿混成大杂烩。
5. 待回答的问题 — 输入中提出但尚未回答的问题。
6. 值得保留的事实 — 持久性背景信息（提及的定价、某人的情况、他们使用的工具）→ 知识库；真正可复用的参考资料 → Keep 笔记（仅当 keep CLI 已通过身份验证时；否则静默跳过）。

名称核验规则： 转录经常会把专有名称听错（品牌名、人名、工具名）。在名称出现在议题标题、知识库页面或回复之前，请对照路由配置、仓库或快速搜索核实拼写——对于可以核实的名称，绝不要相信转录中的拼写。

步骤 3 — 展示路由计划

执行前先列出一张简洁的表格：

#	项目	目标位置
1	“报告页面上的批量导出按钮”	Issue → myorg/acme-app
2	决定：月度计费默认设置	知识库 Projects/Acme.md
3	回复 Jane	下方的草稿

然后无需等待，直接继续——表格中的内容都是内部信息或草稿。仅当路由存在歧义（有两个合理的仓库、找不到对应的人），或输入包含敏感内容（凭据、法律／财务承诺）时，才暂停并请求确认。

步骤 4 — 执行

Issue — 先搜索是否有重复项（gh issue list --search），再使用 gh issue create 在映射的仓库中创建。标题 = 祈使式摘要；正文 = 源内容中的上下文引述、对方提出的要求，以及提出者。若配置中设置了 issue_labels，则应用这些标签。绝不将 Issue 指派给用户以外的任何人。

知识库记录 — 每次导入新建一个文件，使用第二大脑原始数据架构：

# message-jane-bulk-export (2026-09-04)
source: text message from Jane
project: Acme App

## Summary
…

## Decisions
…

## Action items
- [ ] mine: …
- [ ] theirs: Jane to …

## Filed
- myorg/acme-app#123 — Bulk-export button on the reports page

Slug：call- 或 message- + 人员 + 主题。遵循知识库的自动提交约定（每次会话进行一次语义化提交）。

待办事项 — 属于“我”的行动项，也应记录到此人的 vault_page 所跟踪的任务中（若已配置）。

回复草稿 — 使用用户在相应渠道中的语气（配置中的 tone + 渠道惯例：短信 = 简短随意；电子邮件 = 内容更完整）。适用时按以下结构组织：确认收到 → 说明我会采取的行动 → 说明我需要对方提供什么 → 告知对方何时会收到回复。最后以可直接粘贴的区块给出草稿（按照渠道的 /paste 规则撰写，例如 X 帖子正文中不得包含 URL）。绝不发送。

步骤 5 — 汇报

最后简要回顾：输入内容的 TLDR（2–3 句话）、决定、两份行动项清单、已创建 Issue 的链接、知识库文件路径，以及回复草稿。这份回顾就是交付内容——即使从未看过输入的人，也应能了解发生了什么以及接下来要做什么。

配合使用

• second-brain — 记录的内容会存入其 raw/ 架构，以便之后整理
• paste — 为回复草稿设置渠道格式
• deep-research — 当提取出的问题需要实际研究后才能回答时使用
• pm — 当一次通话产生的工作量足以建立项目卡，而不只是创建 Issue 时使用

质量说明

• 最常见的问题是扁平化处理：只总结输入，而不是从中提取工作事项。检验标准：用户是否无需重读源内容就能依据你的输出采取行动？
• 第二常见的问题是Issue 大杂烩。“与 Jane 通话中的改进”不是一个 Issue。一项内容对应一个 Issue，标题清晰明确。
• “对方”的行动项与“我”的行动项同样重要——它们构成后续跟进清单。不要因为没有工具调用来记录，就把它们遗漏。
• 语音备忘录即使没有任何行动项也没问题：记录下来，说明这一点，然后结束。并非每条输入都包含待办事项。