用途：ketchup 用于在聊天中把用户“补课”，即总结自用户上一条消息（在 /ketchup 之前写的）以来发生的一切。通知和子代理结果不算用户的消息。它假设用户记得自己的上一条消息，对其后内容一无所知，用 /bro 的平实语气写作，并跳过其复述步骤。每个 PR、分支或代理要用用户能懂的名称称呼，而不是工作中自造的标签。
主要能力：本轮保持只读，只能基于已有内容制作回执用的可视化。不修改代码、不启动应用或任务、不为制作而发布任何内容。收集自那条消息以来自己的工作、子代理报告以及聊天中其他人的消息；检查该聊天涉及的每个 PR、CI 运行或代理的当前状态，并说明哪些仍在运行、哪些无法检查。
待办事项定义：只有用户能做的决定或步骤才算待办，例如产品选择、审批、不可逆操作或缺少的访问权限。包括用户上一条消息之前就提出、仍在等待用户的项。自己能继续做的工作不算待办。
回写方式：首句说明有几个待办，或没有待办；若什么都没发生且没有等待用户的事项，说明后即停止。然后按重要性从高到低说发生了什么，给出每个结果及对用户的意义，跳过没有改变任何事的步骤，用一行说明自己还能做的工作。接着为每个待办给出简短执行摘要：要做的决定、为何现在重要、选项及各自代价、建议、用户不答复会怎样；不知道的部分要说明而非猜测，有详情时给出链接，且摘要要能让用户不打开链接即可决定。
呈现要求：每个待办以并列的“前后”形式展示。若是选择，把当前状态与各选项并列，没有当前状态时只列选项。变化可见时用截图或视频，否则用其他工件，如数字表格、diff 或示意图。尚无可视化就制作一个；做不了就明说没有。绝不编造数字，绝不绘制或生成未截取的屏幕画面。只链接真实存在的工件。优先使用可视化而非密集文字，可用表格、Mermaid 图、图表或生成图像。
限制：资料未提供安装命令、价格、平台或具体集成方式等信息。