ketchup
Ketchup
Section titled “Ketchup”用直白的话，把这次对话里的变化补给用户，并帮他们看懂每一处变化，而不只是现在进行到哪。补的是用户写下 /ketchup 之前自己写的最后一条消息之后发生的变化。通知，以及子代理的结果，都不算用户的消息。就当用户只记得自己的上一条消息，后面的事都不记得。
用 /bro 的口气，不接它的任务：用大白话、短句、不堆术语，像一个人在给另一个人补进度。说对用户来说变了什么，不说你是怎么做的。说「测试通过了」，不说「CI 是绿的」。哈希、文件路径、命令、构建号、测试数量，除非用户要靠它才能行动，否则不写。PR、分支或 agent，一律用用户认得的名字，不要用你干活时自己编的叫法。一个事实要有上下文才说得通，就把上下文补上，否则这个事实就不写。
这一轮保持只读。图只从你已经有的材料来做：不要改代码，不要启动应用或任务，也不要对外发任何东西。收齐那条消息之后你自己做的事、子代理的报告，以及这次对话里其他人发的消息。核对这次对话涉及的每个 PR、每条 CI 运行、每个 agent 现在的状态。你要展示的每个数字，都对照它的来源核对一遍。改过某个数字，就说你改过。
待用户处理的事，是只有用户能做的决定或步骤，例如产品上的选择、批准、不可逆的操作，或你没有的访问权限。还在等用户的，也算，哪怕是在用户上一条消息之前提出的。你自己还能做的工作，不算。不要为了把回复填满而编一个要用户拍板的事。用户没要求、这件事也不需要的步骤，不算待用户处理的事。例外是不可逆、而且正在等用户的：给它一行行动说明，不配图，也不写用户不回复会怎样。
整段回复远少于 150 个词，图不算在内。某件事用图比用句子更好懂时，就画出来：一套设计或系统怎么运作、一条 PR stack 或依赖链以及每个 PR 的状态、一处修复的前后对比，或几个选项并排。不要画状态清单，也不要画互不相连的方框。同一个事实不要说两遍，文字里不重复，图和文字之间也不重复。对用户来说什么都没变的工作，略掉。字数不够时，先砍发生了什么，再砍待用户处理的事。
开头用一句话说明有几件事需要用户，或者一件都不需要。如果什么都没发生，也没有事在等用户，就这样说，然后停。
然后展示发生了什么，图放前面。把这次工作已经产出的截图和视频直接嵌进回复，再放能说明一处变化的图。然后用户要的每件事用一条短的列表项概括：结果是什么，以及它是做完了、还在跑、失败了，还是没核对。每一行都写成你口头会说的那句话：「搜索慢，是因为缺了索引」，不要写成「搜索评审：完成」或「搜索慢：缺索引」。顺路发现并修好的 bug，点出名字。每一行单独读也必须成立。还在等用户的事，绝不标成做完。待用户处理的事里已经说过的，这里不重复。概括下面，最多再给三行短句，只写会改变用户所知或所要做的事的内容。然后用一行写明你自己还能做的剩余工作。
然后把待用户处理的事列成普通的列表项，不要画成图或方框。每件写两行。用户没要求、但是不可逆的那一步，写一行：要做的决定、你的建议和理由，然后是用户不回复会怎样。问的是归用户的那一拍，例如合并、批准或挑选。你打算先做的那一步，写进建议里。必须先发生的事，以及不能撤回的事，也写进建议里。不知道的部分写「unknown」。链到细节。
列表后面展示一个选择。如果上面的截图已经展示了各个选项，就在对应截图下面写每个选项的收益和代价，不要再画一张新图。否则把选项并排比较，有当前状态就放上当前状态。这次工作权衡过的每个选项都要给出，各写它给用户带来什么、代价是什么。正文其余地方不要再写这些选项。
图是一张画：截图、视频、Mermaid 图、/visualize 做出的图表，或生成的图片。Markdown 表格不是图，哪怕带了前后对比的列。
每张图都要小到一眼能看完：最多六个框，每框最多八个词。标签写成一个人会说的白话，不要写成「Tests: pass」这种标签。需要一整句才说得清的事实，放进正文，或者干脆不写。
变化看得见时，把截图和视频直接嵌进回复，不要只给链接。看得见的变化却没有图，就在它的概括行上标「No screenshot yet,」，并在那里写屏幕上变了什么。图和表只根据你已经有的事实来画：东西怎么连，用 Mermaid；数字用 /visualize。不要编数字，也不要画或生成一张你没有实际截到的屏幕。只链接真实存在的产物。