check

Check：上线前代码审查与把关

在第一行开头内联加上 🥷 符号，不要单独成段。

检查更新（非阻塞）。 每轮对话执行一次 bash <skill-base-dir>/scripts/check-update.sh，需将 <skill-base-dir> 替换为此 Skill 的根目录；若脚本有输出内容则展示，无输出（或脚本已运行过、不存在、执行报错）则静默继续。脚本每天最多检查一次，仅读取公开版本文件，绝不发送任何数据。

注意：/review 是 Anthropic 内置用于 PR review 的插件命令。Waza 改用 /check（或别名 code-review）。请勿在此 Skill 中重新触发 /review。

看 Diff、找问题、安全能改的直接改、剩下的提问。只有在当前对话中运行并通过了验证，才算真正完成（Done）。

交付契约 (Outcome Contract)

• 交付物（Outcome）：基于当前 Diff、项目上下文和实际证据做出的审查意见、发版决策或维护者操作。
• 算完成（Done when）：所有发现的问题、修补代码、已发布状态或阻塞项，均有可证明它们的命令输出、产物（Artifacts）或远端状态支持。
• 证据（Evidence）：工作区（Worktree）状态、Diff、项目公开文档、清单文件（Manifests）、CI 运行状态、包内容、Release 或 Registry 状态，以及当前命令输出。
• 输出格式（Output）：先给出简明扼要的发现/结论，再在适用时附上验证过程与已发布状态总结。

工作区安全预检 (Worktree Safety Preflight)

在进行任何审查、Issue 处理、上线、发版或 PR 操作之前，先运行以下命令查看当前工作区状态：

git status --short --branch -uall

将所有已修改、已暂存（Staged）和未跟踪（Untracked）的文件均视为用户的未完工工作（WIP）。你可以读取它们并将其纳入审查范围，但绝对不能在未获得用户当前轮次明确授权的情况下，对其进行移动、隐藏、覆盖、清理或丢弃。

切勿将以下命令作为默认的 Review 或 PR 准备动作：git switch、git checkout、git reset --hard、git clean、git stash -u、git stash --include-untracked、git stash -a、git stash --all 或 gh pr checkout。如果确实需要切换分支或清理代码，请停下来并明确向用户请求执行该具体操作。

切勿将未跟踪文件、生成的产物、截图或本地临时文件移动到 /tmp 或其他暂存目录中来“保护”用户的工作。擅自将他人的未提交工作移出工作区，与把它 stash 掉属于同等程度的越权干涉。如果生成、打包或验证过程确实需要一个干净的源码树（Clean tree），请基于已知 Commit 建立一个独立的 Git Worktree，并将你产出的 Artifact 或 Patch 复制回当前工作区。

在存在未提交变更（Dirty）或多 Agent 协作的工作区中进行 Commit 或 Push 操作时，暂存前先记录 git rev-parse HEAD。在提交前以及推送前，立即重新读取 git status --short --branch -uall 和 git rev-parse HEAD。如果发现 HEAD 指针移动了、出现了未知的 Commit、或者工作区非目标文件发生了变动，请停止操作并报告状态不一致，而不是擅自进行 Rebase、重新 Commit 或强行 Push。

对于 PR 审查，优先使用不会切换当前工作区的命令：gh pr view、gh pr diff、git fetch origin pull/<n>/head:refs/tmp/pr-<n> 和 git merge-tree。

模式选择器 (Mode Picker)

选择与用户意图相匹配的模式，然后完整阅读该章节内容。以下模式是在后文共享的审查流程（Scope、Hard Stops、Autofix、Specialist Review、Verification、Sign-off）之上叠加的。

用户意图	模式
“按照计划实施”、“implement this plan”、接手 /think 的输出	计划执行模式
Diff 或 PR 已就绪、“review”、“看看代码”、“合并前”	默认审查模式（从 获取 Diff 开始）
“看看 issue”、“审查 PR”、“triage”、“批量处理”	分流处理模式
“这值不值得发个版”、“is this worth a release”	发版价值分析模式
“commit”、“push”、“publish”、“release”、“close issue”、“发布表情”	上线与发版跟进
“audit”、“项目体检”、“项目评分”、“给项目打分”、“深入分析项目代码”、“scorecard”、“linus review”	项目体检模式
文档、PDF、长文审查	转交给 /write（参见 文档审查）

在运行任何模式之前，先执行 项目上下文提取；如果开启了记忆，还需执行 持久化上下文预检。

项目上下文提取 (Project Context Extraction)

这是 Waza 独立的公开代码 Review 能力。它不应依赖私有机器路径或未发布的项目指令。

审查前，先从仓库上下文中提取项目约束条件：

1. 阅读 Diff，识别出变更涉及的语言、框架、清单文件（Manifests）、生成的产物、Release 文件以及 CI 工作流。
2. 仅在需要时检查公开的项目文件：README、已存在的 AGENTS/CLAUDE 指令文档、包清单、Lockfile、构建配置、测试配置、工作流文件和 Release Notes。
3. 将检查发现压缩提炼为审查上下文：验证命令、受保护或自动生成的文件、发布产物、领域风险以及公开回复规则。
4. 当项目上下文与本 Skill 规则重叠或冲突时，严格采用更严格的那一条。
5. 如果项目文档或 CI 中指定了具体的验证命令，优先使用该命令而非自动检测。

关于上下文结构的规格，请参阅 references/project-context.md。

对于发版或维护者相关工作，还需填写 references/project-context.md 中的 Release Gate 2.0 矩阵。该矩阵涵盖审查基线、Dirty/Staged/Untracked 状态、最新 Tag、Origin 同步状态、版本号字段、生成的产物、包/压缩包内容、Release 资产、Registry/Appcast/CI 以及公开 Issue/PR 状态。缺失矩阵证据将作为宣称“已准备好发版”的阻塞项（Blocker）。

持久化上下文预检 (Durable Context Preflight)

关于何时读取持久化上下文、读取顺序预算和记忆类型映射，请参阅 references/durable-context.md。

对于 /check：当前的 Diff、CI 和远端状态的优先级高于记忆。持久化记忆可以解释用户的意图和偏好的后续跟进习惯，但公开的项目规则始终来自 README 文件、清单、CI 工作流、发布文档以及当前对话中的明确指令。绝不能将私有记忆作为公开项目要求来引用。

计划执行模式 (Plan Execution Mode)

当用户的消息以“Implement the following plan”、“按计划实施”、“按照计划”、“整”、“可以干”、“直接改”开头并附带计划主体，或者链接到 /think 的输出时激活此模式。

在此模式下，不要运行代码审查。而是：

1. 声明正在执行哪个计划（输出第一级标题或摘要行）。
2. 检查是否有明显的仓库状态漂移：运行 git status --short --branch -uall，快速浏览是否有与计划冲突的修改文件。如果漂移导致执行计划不再安全，明确指出具体冲突并停止。
3. 将计划中的每一项作为待办事项（To-do）逐步推进。每完成一项便进行标记。
4. 所有事项完成后，运行项目的验证命令。
5. 如果项目上下文或当前对话表明“审查后再上线（review-then-ship）”，则自动过渡到上线（Ship）模式。

默认接续流程 (review-then-ship)

当项目的 AGENTS.md 或当前对话明确要求“review 后提交”、“测试通过就上线”或类似要求时，在审查干净通过后，直接从 Review 流程过渡到 Ship 流程，无需再次询问。在采取行动前声明“正在继续执行上线流程（proceeding to ship）”。

获取 Diff (Get the Diff)

获取当前分支与基线分支（Base branch）之间的完整 Diff。如果已经在基线分支上，询问用户需要审查哪些 Commit。

分流处理模式 (Triage Mode)

当用户提到：issue、PR、“review 所有”、“triage”、“batch”或“批量处理”时激活。跳过 Diff 流程并运行此模式。

行动优先规则（Action-first rule）： 对于处理意图明确的事项（已修复、重复项、已发布），立即执行操作，无需输出分析段落。在分析截图或图片时，在一条消息中说明你看到的内容和建议的操作。只有在处理意图确实存在歧义时才询问用户。

组合诉求拆分（Bundled request classification）： 当单个 Issue、PR 或支持帖子包含多项诉求时，在行动前进行拆分：核心 Bug、已有功能/途径、视觉/偏好样式、超范围诉求。仅修复或关闭已验证的核心 Bug；用现有路径回答已有功能；延后或拒绝视觉偏好及超范围诉求，而不是把整份报告当成一份待办清单。

状态回答顺序（Status answer order）： 对于“都解决了吗”、“is this fixed”、“is this ready”或类似的进度询问，按以下顺序回答：代码或 Commit 状态、分支或 CI 状态、发布产物或 Registry 状态，最后是公开 Issue 或 PR 状态。切勿混淆“在 main 上已修复”、“预发布版可用”、“下一个稳定版推出”与“已正式发版上线”。

流程： 首先从公开上下文识别项目的 Issue/PR 宿主平台。对于 GitHub 项目，使用 gh issue list -R <repo> --state open --limit 20 和 gh pr list -R <repo> --state open 拉取未结事项。对于非 GitHub 项目，使用项目文档或用户请求中指定的平台 CLI/API；如果不存在，停止操作并报告缺失集成，而不是假装 GitHub 命令适用。对于每个事项，结合项目的发布边界检查当前状态：最新公开版本、main 分支、preview/nightly/beta 渠道、registry/appcast 以及目标 Issue/PR 状态。如果修复已在当前公开版本或有记录的预发布渠道中，附上明确的升级路径并关闭。如果在 main 上已修复但未发版，回复“已修复，等下一个版本 release”，仅当项目惯例或当前用户请求允许“main上已修复即关闭”时才关闭；否则保持开启并附上“下版发布”备注。如果尚无修复方案，进行分析并采取行动。如果现在能修复则直接修复（提交 fix: closes #N）；对于有效但未发版的事项，确认并保持开启；对于无效事项，给出一两句原因并关闭。

在实时队列中得出最终结论之前，重新刷新一次 Issue/PR 列表，并重新阅读在此期间发生变动的任何事项。如果证据不完整，暂缓该事项，而不是凭猜测将其关闭。

PR 处理： 如果 PR 方向被采纳但 Patch 需要修改，优先将维护者的修复推送至贡献者的 PR 分支然后合并 PR。先检查 maintainerCanModify，在 Push 前立即确认推送 remote、目标分支和当前 HEAD，以免覆盖贡献者的工作或将维护者的修复推错仓库。如果不允许编辑分支，请贡献者开启维护者编辑权限或推送所需修改；仅在时间紧迫或发版安全确实需要时，才退而求其次使用独立的维护者 Commit，并在 PR 中说明原因。仅当方向被拒绝、不安全、不再需要或明确不属于项目范围时，才在不合并的情况下关闭。切勿将已接受的 PR 静默吸收到 main 中然后将其关闭。

公开回复格式： 加载 references/public-reply.md 获取完整的回复模板（@提及、单次致谢、事实段落、下版发布步骤、编辑规则、关闭标准）。Ship 模式使用相同的模板；该文件为唯一事实来源。

落款签发行（落款附加至标准 Sign-off）：

triage:           N reviewed, N closed, N deferred

发版价值分析模式 (Release Worthiness Analysis)

当用户询问“深入分析 X 是不是值得发新版本”、“is this worth a new release”、“值不值得发版”或类似问题时激活。

<!-- truncated for translation batch; full body continues in source -->