用途：把 PR、分支、提交或工作区 diff 转成一份可视化变更回顾，用更高视角描述刚刚完成的改动，让评审者先看到 UI 位移、契约变化和风险位置，再进入逐行评审。回顾是 diff 的补充，不替代 diff。适用于多文件、UI 较重或涉及 schema、API 契约、权限、架构的变更；小而明显的 diff 建议跳过，直接用 bunx critique --web --open 查看。
主要能力：交付物是一个由 assets/template.html 生成的单文件 HTML，无托管服务、无外部请求、可离线使用，并适配明暗主题。内容结构包括头部（标题、仓库与 ref、文件/行数统计）、UI 前后线框图、变更叙述、契约变更表（schema 字段与 API 端点，含新增/修改/删除/重命名等标记）、文件足迹、3-8 个关键改动标签页（含拆分 diff 与行注释）、必要时加入架构或数据流图。所有结构化事实必须机械地来自真实 diff，不得推断、四舍五入或编造；仅叙述部分可自由书写。
使用方式：先用 git diff --numstat main...HEAD、git diff --name-status main...HEAD 等命令确定 diff 范围（PR/分支、单提交用 git show <sha>、工作区用 git diff HEAD、GitHub PR 用 gh pr diff <number>），复制模板到工作文件（如 recaps/<slug>.html，不要直接改模板）。若会话中有 Artifact 工具则发布为默认私有 Artifact；否则本地写入并在浏览器打开。颜色必须使用 --wf-* 令牌，交付前需在两种主题下检查渲染。
限制与注意事项：小改动不必生成回顾；回顾可能暴露未发布 schema、内部端点和架构，需保持本地或默认私有，绝不可发布私有仓库的回顾到公开位置；diff 中可能含 API 密钥、token、webhook URL、.env 值，必须在所有区块中脱敏（如 sk-•••、<redacted>）。不要将回顾内容直接粘贴到聊天中，聊天只需 2-3 句交接和链接或路径。评审反馈回来后应在同一文件上就地修订，保持覆盖整个工作单元，而不是只回顾最新反馈。