ketchup

Ketchup

告诉用户，自他们在 /ketchup 之前最后一次发消息以来，这段聊天里有哪些变化，并帮助他们理解每项变化，而不只是说明当前进展。然后列出所有等待他们处理的事项，让他们仅凭你的回复就能作出决定。通知和子 Agent 的结果不算用户发的消息。假设用户记得自己最后发的消息，但不记得之后发生的任何事。

使用 bro 技能。借用它的语气，而不是它的任务：用词平实，句子简短，不用行话，就像一个人在向另一个人说明近况。说明发生了哪些与用户有关的变化，而不是你是怎么做的。说“测试通过了”，不要说“CI 是绿色的”。除非用户需要这些信息来采取行动，否则省略哈希值、文件路径、命令、构建编号和测试数量。提及 PR、分支或 Agent 时，使用用户能认出来的名称，不要使用你自创的标签。如果某个事实需要背景才能理解，就补上背景，否则就省略。

收集变化

本轮只读。只能使用已有信息制作可视化：不要更改代码、启动应用或任务，也不要发布任何内容。收集自用户那条消息以来你完成的工作、子 Agent 的报告，以及聊天中其他人的消息。检查这段聊天涉及的每个 PR、CI 运行或 Agent 的当前状态。核对你准备展示的每个数字是否与其依据一致；如果更正了数字，要说明这一点。

待办事项是只有用户才能作出的决定或采取的步骤，例如产品选择、批准、不可逆操作，或你缺少权限时需要用户提供的访问权限。包括所有仍在等待用户处理的事项，即使它们是在用户最后一条消息之前提出的。你自己还能完成的工作不算待办事项。不要为了凑数而编造需要用户决定的事项。如果某个步骤不是用户要求的，且工作也不需要它，就不算待办事项；除非它不可逆且正在等待用户决定：这种情况用一行说明，不要附带可视化。

一项待办可以涵盖多个事项，例如一组等待合并的 PR。对每个事项，收集其链接、它会给用户带来的变化、支持你判断的证据、风险，以及你的建议。如果作出决定所需的某项事实未知，就写“未知”。没有链接就不要提供。

撰写回复

多写具体进展，少讲故事。事情经过控制在 100 词以内，不计图片；如果进展较少，就写得更短。省略对用户没有任何影响的工作。每项约 30 词。回复长度随事项数量增加：两项合计应远少于 150 词，不计图片；三十项则会长得多。不要为了遵守字数限制而删减或压缩事项：不能用数量代替列表，也不能用链接代替事项。链接可以补充细节，但仅凭回复本身也必须足以作出决定。

开头用一句简短的话说明有哪些事需要用户处理，或者说明没有需要处理的事。具体细节放在行动项里。如果什么都没发生，也没有需要用户处理的事，就说明这一点，然后结束。

接着展示进展，先放图片。内嵌工作产生的截图和视频，然后再放能说明变更的图表。之后针对用户提出的每件事，各用一个简短的项目符号总结结果，以及该事项已完成、仍在进行、失败还是尚未检查。每行都要像平时说话那样写：“缺少索引导致搜索变慢”，不要写成“搜索检查：已完成”或“搜索慢：缺少索引”。说明过程中发现并修复的任何 bug。每行单独阅读时也必须准确。不要把仍需用户处理的事项标成已完成，也不要写行动项中提到的内容。摘要下方最多写三行简短说明，且只写会改变用户认知或需要用户采取行动的内容。最后用一行说明还有哪些工作可以由你自行完成。

然后列出行动项。明确询问用户需要作出的决定，例如合并、批准或选择，并说明你的建议。你建议优先采取的步骤要写在建议中。任何必须先完成的事项，以及任何无法撤销的操作，也要写在建议中。每个需要作出决定的 PR、issue 或 Agent 都要给出编号或链接；涉及多个选项时，也要在选项对应的决定中给出。

根据决定的类型调整结构。只有一项的决定写成一个项目符号：说明要作出的决定、你的建议、对用户的影响、支持建议的证据，以及风险，并且只提一次该事项的名称。多个事项共用一个决定时，先写一次决定和建议，然后按风险从高到低，为每个事项单独写一个项目符号：提供链接和名称、对用户的影响、支持建议的证据，以及风险。仅当某项的建议与整体决定不同时，才单独说明该项的建议。每项都要说明风险，即使风险很低，例如“低风险：只有颜色会变化”。只有当等待的代价不只是延迟时，才说明等待的损失，例如错过截止日期或丢失数据。

需要在多个选项中作出决定时，逐一说明每个选项的权衡，包括它能为用户带来的好处、需要付出的代价，以及当前状态（如有）。这些代价就是该决定的风险，因此不要再单独列出风险。如果上方截图展示了各个选项，就在对应截图下方说明各选项的收益和代价。

可视化内容

可视化内容是图片：屏幕截图、视频、Mermaid 图表、渲染后的图表或示意图，或生成的图片。Markdown 表格不属于可视化内容，即使包含前后对比列也是如此。

如果用图片比用句子更容易理解，就画出来：设计或系统的工作方式、PR 堆栈或依赖链及每个 PR 的状态、修复前后的对比，或并排展示的选项。不要画状态列表、待办事项列表，也不要画彼此没有连接的方框。不要在文本或可视化内容中重复呈现同一事实。

每个可视化内容都要足够精简，让人一眼就能看清：最多六个方框，每个方框最多八个词。标签要用人们平时会说的普通词语，不要写成“测试：通过”之类的标签。需要用句子表达的事实应放在文本中，或者干脆不写。

如果更改效果可见，请将屏幕截图和视频直接嵌入内容中，而不只是提供链接。如果可见的更改没有截图，请在摘要行标注“No screenshot yet,”，并在该行说明屏幕上发生了什么变化。图表和示意图必须根据已有事实绘制：用 Mermaid 图表说明事物之间的关联，用渲染后的图表展示数字。绝不编造数字，也绝不绘制或生成没有实际拍摄过的屏幕图片。只链接已存在的附件。