ketchup

Ketchup

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，都是与此技能目录并列的 ../<name>/SKILL.md 文件；不带前缀的原则名称对应 ../principle-<name>/SKILL.md。请读取该文件并遵循其中的要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。

向用户说明自他们在 /ketchup 之前最后一条消息以来，这段聊天中发生了哪些变化，并帮助他们理解每项变化，而不只是说明当前状态。然后列出所有等待他们处理的事项，让他们只看你的回复就能采取行动。通知和子 Agent 的结果不算他们发出的消息。假设用户记得自己的最后一条消息，以及之后发生的所有事情。

用 /bro 的表达方式，而不是执行它的任务：用词朴素，句子简短，不用术语，就像一个人向另一个人说明近况。说明对用户而言发生了什么变化，而不是你是如何做到的。说“测试通过了”，不要说“CI 是绿色的”。除非用户需要，否则不要提哈希值、文件路径、命令、构建编号和测试数量。称呼每个 PR、分支或 Agent 时，使用用户熟悉的名称，不要自行编造标签。如果某个事实需要背景才能理解，就补充背景，否则省略。

收集变化

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

待办事项是只有用户才能做出的决定或采取的步骤，例如产品选择、批准、不可逆操作，或你缺少访问权限。包括所有仍在等待用户处理的事项，即使这些事项是在用户最后一条消息之前提出的。你自己仍能完成的工作不算待办事项。不要为了凑数而编造待用户决定的事项。用户未要求、且工作不需要的步骤不算待办事项；但如果该步骤不可逆且正在等待用户决定，则要用一行说明，不要配图。

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

撰写回复

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

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

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

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

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

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

可视化内容

可视化内容是图片：截图、视频、Mermaid 图表、你构建并通过 html_preview、再通过 html_render 展示的页面中的图表或示意图，或生成的图片。Markdown 表格不是可视化内容，即使它包含修改前后两列。

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

每个可视化内容都要小到一眼就能看清：最多六个方框，每个方框最多八个词。标签用人们日常会说的词语，不要用像“Tests: pass”这样的标记。需要用句子表达的事实应放在文本中，否则就不呈现。

如果截图和视频（preview_* 或 device_* 捕获内容）能展示变更，就将它们内嵌展示，而不只是提供链接。如果可见变更没有相关内容，就在摘要行标注“No screenshot yet,”，并说明屏幕上发生了什么变化。根据已有事实绘制图表：用 Mermaid 图表展示事物之间的连接关系；对于数字，构建图表页面并通过 html_preview、再通过 html_render 展示。绝不要编造数字，也绝不要绘制或生成未捕获的屏幕图片。只链接实际存在的制品。