ketchup

Ketchup

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

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

收集变化

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

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

撰写回复

整篇回复控制在 150 词以内，不计视觉内容。若图示比文字更容易说明问题，就画出来：例如设计或系统的工作方式、PR 堆栈或依赖链及每个 PR 的状态、修复前后对比，或并列展示选项。不要画没有连接线的状态列表或方框。不要在文字或视觉内容中重复任何事实。略去没有给用户带来变化的工作。字数不够时，先删减发生了什么，再删减行动项。

开头用一句话说明有多少事项需要用户处理，或说明没有。如果什么都没发生，也没有事项需要用户处理，就这样说明并结束。

然后说明发生了什么，先放图示。内嵌展示工作产出的截图和视频，然后再放解释变更的图表。接着按用户提出的每项请求，用一个简短项目符号总结结果，以及该事项已完成、仍在运行、失败还是未经检查。每行都要像口头表达一样自然：“搜索因缺少索引而变慢”，而不是“搜索审查：完成”或“搜索缓慢：缺少索引”。指出过程中发现并修复的任何 bug。每行单独阅读时都必须属实。仍需用户处理的事项不能标为已完成，也不要提及行动项中已经说明的内容。总结下方最多写三行简短内容，只包含会改变用户认知或需要用户采取行动的信息。然后用一行说明你还可以自行完成的剩余工作。

随后用普通项目符号列出行动项，绝不能用图表或方框表示。每项写两行；对于未被要求且不可逆的步骤，只写一行：先写建议采取的决定及理由，再写用户不回复时会发生什么。询问由用户决定的事项，例如合并、批准或选择。建议中应包含你会优先采取的步骤，以及必须先做的事和不可撤销的事。不知道的部分写“未知”。附上详细信息链接。

列出行动项后展示选项。如果上方的截图已展示选项，就在每张截图下方分别写出每个选项的收益和代价，不要另画新图；否则，并列比较各选项，并在适用时说明当前状态。每个选项都要包含所权衡的工作，以及能为用户带来的好处和代价。选项内容不得出现在其他文本中。

视觉内容

视觉内容是指图片：截图、视频、Mermaid 图表、可由运行环境渲染的图表或示意图，或生成的图片。Markdown 表格不算视觉内容，即使包含前后对比列也不算。

每个视觉内容都要小到一眼即可看清：最多六个方框，每个方框最多八个词。标签应使用人们日常会说的词语，不要写“测试：通过”之类的标签。需要用句子说明的事实，应写在正文中，或完全省略。

当变更可见时，应直接内嵌截图和视频，而不只是提供链接。如果可见变更没有截图，在对应的总结行中标注“尚无截图”，并说明屏幕上发生了什么变化。根据已有事实绘制图表：用 Mermaid 图说明事物之间的关联，用渲染后的图表展示数字。不得编造数字，也不得绘制或生成未实际截取的屏幕图像。只能链接到确实存在的素材。