ketchup

Ketchup

告诉用户，自他们在 /ketchup 之前写的上一条消息以来，这段聊天中发生了哪些变化，并帮助他们理解每项变化，而不只是说明当前进展。通知和子 Agent 的结果不算用户的消息。假设用户记得自己的上一条消息，以及此后发生的一切都不记得。

使用 /bro 的语气，而不是它的任务风格：措辞朴实，句子简短，不用术语，就像一个人在向另一个人说明近况。说明用户这边发生了什么，而不是你是如何做到的。说“测试通过了”，不要说“CI 是绿色的”。除非用户需要这些信息才能采取行动，否则不要提哈希值、文件路径、命令、构建编号和测试数量。用用户熟悉的名称称呼每个 PR、分支或 Agent，不要用你自己编造的标签。如果某个事实需要背景才能理解，就补充背景；否则就略过。

收集变化

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

待办事项是只有用户才能做出的决定或采取的步骤，例如产品选择、批准、不可逆操作，或你缺少所需访问权限。所有仍在等待用户处理的事项都要列出，即使它是在用户上一条消息之前提出的。你仍能自行完成的工作不算待办事项。不要为了凑内容而编造需要用户决定的事项。对于用户没有要求、工作也不需要的步骤，除非该步骤不可逆且正在等待用户决定，否则不要列为待办事项；如果要列，只写一条行动项，不要配图，也不要说明用户不回复会有什么后果。

撰写回复

整篇回复（不计视觉内容）控制在 150 词以内。如果图片比文字更容易说明问题，就画出来：例如设计或系统的工作方式、PR 堆栈或依赖链及每个 PR 的状态、修复前后对比，或并列展示选项。绝不要画没有连接线的状态列表或方框。绝不要在文字中或视觉内容中重复事实。省略对用户没有影响的工作。字数不够时，先删减已发生的事项，再删减待办事项。

开头用一句话说明有多少事项需要用户处理，或说明没有。如果没有任何进展，也没有任何事项需要用户处理，就说明这一点并停止。

接着说明发生了什么，先展示图片。内嵌工作产生的截图和视频，然后展示解释变更的图表。接着针对用户提出的每件事，用一条简短的项目符号概述结果，以及状态是已完成、仍在运行、失败还是未检查。每行都要像口头表达一样自然：“搜索因缺少索引而变慢”，而不是“搜索审查：已完成”或“搜索缓慢：缺少索引”。提及过程中发现并修复的任何错误。每一行单独阅读时都必须准确。仍需用户处理的事项不得标记为已完成，并且不要提及待办事项中已有的内容。在摘要下方，最多用三行简述会改变用户认知或需要用户采取行动的信息。最后用一行说明你还能自行完成的剩余工作。

然后用普通项目符号列出待办事项，绝不要画成图表或方框。每项写两行；若是未经请求且不可逆的步骤，则写一行：先给出建议及理由，再说明用户不回复时会怎样。提出由用户决定的事项，例如合并、批准或选择。你的建议应包含你会先采取的步骤，也应包含任何必须先完成的事项及任何不可逆的事项。不了解的部分写“未知”。附上详情链接。

列出待办事项后，展示选项。如果上方截图已展示选项，就在各自截图下方写出每个选项的收益和代价，不要另画视觉内容；否则并列比较选项，并在有当前状态时一并展示。列出所有权衡过的选项，每个选项都要说明能为用户带来什么以及需要付出什么代价。不要在其他文字中提及这些选项。

视觉内容

视觉内容是图片：截图、视频、Mermaid 图表、来自 /visualize（Cursor）或你的工具环境的图表工具所生成的图表，或生成的图像。Markdown 表格不是视觉内容，即使包含前后对比列也一样。

每个视觉内容都应简洁易读，一目了然：最多六个方框，每个方框最多八个词。标签应使用自然的词语，而不是“测试：通过”这类标记。需要用句子说明的事实应写在文字中，或干脆省略。

如果变更能通过截图或视频呈现，就将其内嵌展示，而不只是提供链接。如果有可见变更却没有截图，在对应摘要行标注“暂无截图”，并说明屏幕上发生了什么变化。根据已有事实绘制图表：用 Mermaid 图表说明事物之间的关联，用图表展示数字（使用 Cursor 中的 /visualize 或你的工具环境中的图表工具）。绝不要编造数字，也绝不要绘制或生成未实际捕获的屏幕图像。只链接实际存在的文件。