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