ketchup

Ketchup

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

用 /bro 的语气，而不是它的任务：用平实的词，句子简短，不用行话，像一个人在向另一个人说明近况。说清楚用户面临的变化，而不是你是如何完成工作的。说“测试通过了”，不要说“CI 是绿色的”。省略哈希、文件路径、命令、构建编号和测试数量，除非用户需要这些信息才能采取行动。称呼每个 PR、分支或 Agent 时，使用用户熟悉的名称，而不是你自己编造的标签。若某条事实需要背景才能理解，就补上背景，或者省略这条事实。

收集变化

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

待办事项是只有用户才能作出的决定或采取的步骤，例如产品选择、批准、不可逆操作，或你缺少访问权限的事项。包括所有仍在等待用户处理的事项，即使它是在用户最后一条消息之前提出的。你自己仍能完成的工作不算待办事项。不要为了填满回复而编造决定。若某个步骤是用户没有要求且工作也不需要的，除非它不可逆且正在等待用户决定，否则不算待办事项；这类步骤只用一行说明，不要配图。

一个决定可以涵盖多个事项，例如一组等待合并的 PR。对每个事项，收集其链接、对用户的影响、支持你推荐的证据、风险，以及你的建议。对于决定所需但你不知道的事实，写“未知”。没有链接就省略链接。

撰写回复

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

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

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

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

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

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

可视化内容

可视化内容是图片：截图、视频、Mermaid 图表、通过 /visualize（Cursor）或你的运行环境中的图表工具生成的图表或示意图，或者生成的图片。Markdown 表格不是可视化内容，即使包含前后对比列也不例外。

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

每张可视化内容都要小到一眼就能看清：最多六个方框，每个方框最多八个词。标签要用人们会说的普通词语，不要使用“测试：通过”之类的标签。需要用句子说明的事实应写在正文中，或者干脆不写。

如果变更能通过截图或视频直观呈现，就在正文中嵌入截图或视频，而不只是添加链接。如果有可见变更却没有截图或视频，请在摘要行标注“暂无截图”，并在该行说明屏幕上发生了什么变化。根据你掌握的事实绘制图表：用 Mermaid 图表展示事物之间的连接关系，用图表展示数字（在 Cursor 中使用 /visualize，或使用你的运行环境中的图表工具）。不要编造数字，也不要绘制或生成你没有截取过的屏幕图片。只链接实际存在的内容。