ai-diff-reviewer

AI Diff Reviewer — 本地与 CI 搭档工具

AI Diff Reviewer 是一个 GitHub Action，可在 CI 中对每个拉取请求运行大模型审查。此技能是它的本地对应版本——由你的编码 Agent（Cursor、Claude Code、Codex、Gemini、Copilot、Cline、Windsurf、Grok CLI、Pi、OpenCode）驱动，在你当前正在编辑的分支上运行同一套审查器。它还会在你的代码库尚未配置 CI Action 时，为你安装并配置该 Action。

面向两类用户，同一个技能。

• 如果你的代码库已经在 CI 中运行该 Action → 在本地使用此技能，提前几秒发现 CI 会发现的问题。当 CI 使用相同的扩展文件进行配置 （prompt-extension-file: .review/extension.md）时，本地与 CI 审查结果一致——使用相同的基础提示词和覆盖设置。有关配置详情，请参阅下文的“对等保证（流程 B）”部分。
• 如果你的代码库尚未配置该 Action（或你不想配置）→ 此技能仍会在本地提供完整审查；等你准备就绪时，它还会帮助你在 CI 中安装该 Action，并为严格程度、触发条件和外部贡献者策略设置合理的默认值。

六项协同能力，根据意图分流：

#	能力	子技能	使用环境
1	对当前分支运行审查	（默认流程——此文件）	🖥️ 本地
2	编写代码库专属覆盖设置（.review/extension.md）	generate-extension	🖥️ 本地 + ☁️ CI（共享文件）
3	安装 GitHub Action + 编写 pr-review.yml	setup	☁️ CI
4	根据差异草拟 PR 标题和正文	open-pr	🖥️ 本地 → GitHub
5	在 PR 中读取 CI 审查结果（优先使用 v3 结构化输出产物，缺少时则回退到审查线程）+ 逐条查看问题并决定应用、延期或跳过	apply-review	☁️ CI → 🖥️ 本地
6	一次调用完成整个闭环：检查每个工作流和 PR 运行状态，等待审查当前最新提交，处理审查发现的问题（应用 → 提交 → 推送），修复失败的工作流（代码检查、测试、分支未同步到最新），并按照此代码库的触发方式重新启用审查器（切换标签或推送）——如果 PR 创建时没有触发标签，也会启用第一轮审查	address-review	☁️ CI → 🖥️ 本地 → ☁️ CI

子技能 3（setup）还通过 setup/reference.md 提供了每个 action.yml 输入项的参考手册——任何 Agent 都能回答*“strictness 有什么作用？”*，而不必打开 Action 源码。

版本对等。 此技能中的 prompt.md 与 Action 在同一标记版本中附带的文件逐字节相同（由 CI 的 Skills — prompt-sync invariant 作业强制保证）。 在两处都固定使用 @v2.1.0，即可确保采用相同的方法和严重程度模型（CI 可能会在第 2 轮及后续轮次通过 Iteration-Aware Review 进一步去重；本地审查始终进行完整审查）。

来源：https://github.com/DailybotHQ/ai-diff-reviewer · 许可证：MIT

---

两种受支持的流程：仅本地或双端协作

六个子技能彼此独立。它们没有先后顺序要求，安装 CI GitHub Action 并非在本地使用此技能的前提条件。每个使用此技能的代码库都属于以下两种流程之一——请选择符合该代码库使用场景的流程：

流程	适用场景	要运行的子技能	要跳过的子技能
A. 仅本地	你希望编码 Agent 在当前分支上采用相同的审查方法，但不希望每次 PR 都在 CI 中触发审查。常见于个人仓库、实验性仓库，以及团队尚未选择自动 PR 审查的仓库。	**可选但建议：**运行一次 generate-extension，定制 .review/extension.md。然后在每个分支上运行父级 run a local review 流程——无论是否有扩展文件都能正常运行（如果在第 2.5 步选择跳过，则回退到随附的基础提示词）。最后也可运行 open-pr。	setup——不要运行。它会写入 .github/workflows/pr-review.yml，从而启用 CI Action。apply-review——没有需要应用的内容（未安装 Action 时，CI 审查不会回传到 PR）。
B. 双端	你希望同时进行推送前的本地预审和每个 PR 的完整 CI 审查，并在两端采用相同的审查方法和严重性模型（CI 还可能在第 2 轮及后续轮次通过 IAR 去重——见下文）。推荐用于团队仓库及任何面向生产环境的项目。	运行一次 setup（安装 CI Action，并接受第 5 步移交给 generate-extension），然后在每个分支上运行父级 run a local review 流程。PR 准备就绪时运行 open-pr。推送后，CI 发布审查结果后，运行 apply-review 读取发现项，再运行 address-review 完成整个流程（解决发现项、修复 PR 所运行的其他失败工作流、提交、推送并重新触发审查器）。	无——整个生命周期中会用到全部五项功能。

一致性保证（流程 B）。 当 setup 写入工作流并配置 prompt-extension-file: .review/extension.md 时（接受第 5 步移交给 generate-extension 后的默认设置），CI Action 会读取本地 Agent 使用的同一个文件。相同的基础提示词 + 相同的 扩展文件 = 本地和 CI 中相同的审查方法与严重性模型。CI 在某一代的 第 2 轮及后续轮次中仍可能给出更精简的发现项，因为迭代感知审查会在此处进行去重（本地审查不会——见下文）。如果拒绝第 5 步的移交，setup 会省略 prompt-extension-file，此时只有基础提示词保持一致—— 你之后可以手动添加此输入，或重新运行 setup 并接受 移交。

仅限 CI 的功能（本地不会同步）。 以下三项 Action 功能 仅在 GitHub Actions 中运行，不会用于此技能的本地审查流程 （本地审查使用编码 Agent 当前采用的模型——Action 的提供方、api-base 选择及其使用情况遥测均不适用）：

1. 迭代感知审查（IAR）——跨轮次基于内容锚点去重，提供四种收敛策略（默认值为 first-pass-exhaustive）、退出标签（full-review-please）以及用户强制重置（移除 applied-label 后重新触发）。 本地审查始终会针对当前差异执行完整审查——因此可能会发现 CI 在同一代的第 2 轮及后续轮次中已去重的结果。规范： docs/ITERATION_AWARENESS.md。 调优示例： examples/iteration-aware.yml。
2. skip-review-label 紧急绕过——当 PR 上带有配置的标签时，CI 会直接以成功状态结束，不调用大模型。仅用于热修复／回滚；请使用规则集保护该标签。规范： docs/TRIGGER_MODES.md § Emergency-bypass。 示例： examples/skip-review-label.yml。
3. 增量后续轮次＋用量遥测（v2.1.0+）——从第 2 轮开始，CI 只审查自上次审查以来的变更，以及仍未解决的自身发现项（解决声明仅供参考；由维护者解决讨论串——或者从 v2.3.1 起，如果讨论串 collapse-previous 已将其折叠，运行时会移除已获佐证的修复），且每次 CI 审查都会以 **Usage:** 行结束（令牌数、缓存命中率、轮次数、费用）。本地审查会完整审查，且不会显示用量行。规范： docs/ITERATION_AWARENESS.md § 14。

完整输入参考（包含所有 IAR 配置项和 skip-review-label）位于 setup/reference.md。

向 Agent 说明工作流。 如果含糊的请求“设置审查器”可能指两种工作流中的任意一种，Agent 会询问。若要跳过此问题，请在每个仓库首次设置时明确说明：

• 工作流 A：“为本地使用设置 ai-diff-reviewer——不要安装 GitHub Action。”
• 工作流 B：“完整设置 ai-diff-reviewer——安装 Action 工作流并生成扩展文件。”

在该仓库中的所有后续请求（“审查我的分支”、“打开 PR”等）在两种工作流下的操作方式都相同——工作流的区别只在首次设置时才重要。

---

安装

# Latest v2.x
npx skills add DailybotHQ/ai-diff-reviewer --skill ai-diff-reviewer

# Or pin to a specific tag for reproducibility
npx skills add DailybotHQ/[email protected] --skill ai-diff-reviewer

这会将此技能安装到使用方仓库的 .agents/skills/ai-diff-reviewer/ 中，并将来源和内容哈希记录在 skills-lock.json 中，使任何队友都能使用 npx skills experimental_install 恢复完全相同的字节。使用 npx skills update ai-diff-reviewer 更新到最新版本。

关于 git 仓库标识的说明。 仓库路径仍为 DailybotHQ/ai-diff-reviewer（历史原因——从 v1.0.0 起发布的标签，以及当前主版本 @v2）。--skill ai-diff-reviewer 标志 与 Marketplace 上的名称一致；两者指的是同一产品。

---

激活

frontmatter 中的 description 仅包含精简的路由摘要 （宿主会将其限制在 1,024 个字符以内）；完整的触发条件目录位于此处，并作为路由依据。

默认工作流（运行审查）——触发条件：

• “审查我当前的分支”
• “对我的变更运行代码审查”
• “推送前做一次预检审查”
• “针对 main 审查此差异”
• “CI 会如何评价我当前的提交？”
• “针对 <rev> 审查”、“审查自 <rev> 以来的范围”， /ai-diff-reviewer --base <rev>（显式指定基准——步骤 1）

生成扩展文件工作流——触发条件：

• “为此仓库生成 .review/extension.md”
• “为我们的项目自定义代码审查”
• “帮我编写仓库专属的审查规则”
• “根据我们的技术栈定制审查器”

设置工作流（安装 GitHub Action）——触发条件：

• “为此仓库设置 AI Diff Reviewer”
• “配置 reviewer 操作”
• “安装 AI Diff Reviewer GitHub Action”
• “帮我创建 pr-review 工作流”
• “如何将 AI Diff Reviewer 添加到此项目？”
• “如何设置 ai diff reviewer？”（不区分大小写）
• 也会通过 setup/reference.md 响应有关该操作的参考类问题，例如 “strictness 有什么作用？”、“如何使用 label-gate？”。

Open-PR 流程（编写拉取请求）——触发语：

• “打开 PR”“为此分支创建拉取请求”
• “拟定 PR 标题和描述”
• “编写 PR 正文”
• “更新 PR 描述”“按正确格式重写 PR 正文”
• “创建草稿 PR”（添加 --draft）

Apply-review 流程（读取并应用 PR 上的 CI 评审）——触发语：

• “CI 评审说了什么？”
• “读取此 PR 上的评审”“给我看看评审发现的问题”
• “应用 AI 评审的修复”“带我了解这些发现”
• “帮我处理严重问题”“只看严重问题”
• “哪些发现阻止了合并？”
• “机器人发布了评审——帮我处理一下”

Address-review 流程（一次调用即可完成闭环）——触发语：

• “处理评审并重新运行”“解决评审者的评论并切换为就绪状态”
• “修复评审发现的问题并重新触发 CI”“修复失败的工作流”， “让 CI 变绿并重新运行 reviewer”
• “循环处理评审” / “运行评审循环”
• “此 PR 还没有评审——触发评审”（冷启动——该流程涵盖两种触发模式）
• 在全新上下文中直接调用——只说“循环处理评审”，没有 PR 编号，也没有其他内容——信息已充分：目标是当前分支的 PR；如果尚未触发评审， 则启动评审也是循环流程的一部分。直接路由到 address-review。

如果触发意图不明确（例如，开发者在尚无 .review/extension.md 的仓库中说“帮我处理 评审”，或在 PR 既需要评审又只有一行正文的仓库中说“处理 PR”），请先提出一个澄清问题，再进行路由。以下判断依据有助于消除歧义：

• 仓库已有 .github/workflows/pr-review.yml（或类似文件） → 很可能不是 setup 流程。
• 仓库没有 .github/workflows/pr-review.yml（或名称类似的 AI Diff Reviewer 工作流——在 .github/workflows/ 目录树中 grep DailybotHQ/ai-diff-reviewer 或 ai-diff-reviewer 操作引用） 且没有 .review/extension.md，并且开发者刚安装了该技能 → 询问他们想要哪一种流程（“流程 A 仅本地”或“流程 B 双界面”；参见上文“支持的两种流程” 一节）。不要默认选择 setup——流程 A（仅本地）是正式支持的用例，未经请求运行 setup 会 写入 .github/workflows/pr-review.yml，并将 CI Action 强行引入开发者可能不想启用它的仓库。存在无关工作流（CI 测试、部署流水线、依赖机器人） 不能作为选择流程 B 的依据；只有 ai-diff-reviewer 工作流才可以。
• 开发者刚完成一轮代码修改，尚未请求评审 → 默认走评审流程（本地）。
• 如果当前分支已有 PR，且最近一次 CI 运行发布了实时 `` 评论，那么 “评审” 一词存在歧义。在这种情况下，“读取评审” 通常指 PR 上的 CI 评审（apply-review 流程），而不是重新进行本地评审。 只需询问一次：“是读取刚刚发布到 PR #N 的 CI 评审，还是在你的工作树上运行一次新的本地评审？”——“循环处理评审” / “处理评审” 不属于这种歧义：明确表达循环意图时，无需询问，直接路由到 address-review。
• 开发者刚接受了本地评审的发现并应用了修复 → 很可能进入 open-pr 流程（自然的下一步，也是本次会话中的第一个 PR）。
• 开发者刚应用了 CI 评审中的修复 → 很可能以编辑模式运行 open-pr （如果范围发生变化，则刷新 PR 正文），然后执行 git commit + git push（由他们自行操作）。 有些 harness（Claude Code、Cursor）也会将这些功能公开为斜杠 命令（/ai-diff-reviewer、/ai-diff-reviewer-generate-extension、 /ai-diff-reviewer-setup、/ai-diff-reviewer-open-pr、 /ai-diff-reviewer-apply-review）；请查阅相应 harness 的 技能调用文档。

---

默认流程：本地审查如何运作

以下所有内容（步骤 0 至 5）仅描述上表中的能力 #1 ——审查当前分支。四个相关子技能各自在对应的 SKILL.md 文件中定义了自己的流程：

• generate-extension/SKILL.md — 编写 .review/extension.md
• setup/SKILL.md — 安装 GitHub Action
• open-pr/SKILL.md — 编写 PR 标题和正文
• apply-review/SKILL.md — 阅读并应用 PR 上发布的 CI 审查（自 v3 起优先使用制品：review-output/3.0 文档包含审查结果、验证、驳回的审查结果和此前的记录；讨论串作为后备）

---

专属 orchestra 审查者

当负责人分配独立审查任务时，请先阅读 orchestra.md，再执行默认流程。该文件介绍了如何使用 ak pick 选择不同的供应商／账户、在共享的基础检出中审查冻结的基础版本／头版本范围、通过 herdr-peers 返回审查结果，以及负责人的合并门槛。该任务分配不会扩大此技能的写入范围。

---

步骤 0 — 信任边界

此技能对工作树近乎只读，且不会 调用任何远程 API。它会：

• 从当前 git 检出中读取文件（Read、Grep、Glob）。
• 在本地运行 git diff 和 git log（不推送、不获取）。
• 在 Agent 的上下文中编写审查提示词，并将审查结果输出到终端。

它可能执行的唯一写入操作，且仅限步骤 2.5 中获得开发者明确同意后：

• 创建 .review/ 并写入 .review/extension.md——如果开发者对初始化提议回答是（调用 generate-extension 子技能）。
• 创建 .review/ 并创建 .review/.skip-bootstrap（0 字节）——如果 开发者对初始化提议回答永不。

它不会：

• 向 GitHub 发布行内评论（这是 CI Action 的工作）。
• 修改工作树中的任何源文件、工作流或配置文件。
• 直接调用 LLM 供应商——它使用已经在运行你的编码 Agent。
• 将任何数据发送到你的计算机之外。

如果编码 Agent 拥有更广泛的权限（例如可以写入文件或运行任意 bash 命令），这些权限来自 harness，而非此技能。

---

步骤 1 — 检测上下文

运行以下命令以确定审查的输入。将 JSON 输出到工作上下文中；除非用户要求，否则不要打印给用户。

显式基础版本（--base <rev>）。 当请求中指定了基础版本—— --base <rev>、“针对 <rev> 进行审查”、“审查自 <rev> 以来的范围”—— 请在运行代码块前将 REVIEW_BASE 设为该版本。任何 git 可解析为提交的版本都有效：SHA、标签、分支、HEAD~5。单独的分支名称表示本地分支；远程分支请传入 origin/<branch>。 需要 git ≥ 2.24（--end-of-options）。它的优先级高于 跟踪的上游分支，因此 Deep Work Plan Final Review 可以准确审查计划范围（其起始提交），而不是分支所跟踪的范围。 默认检测时请将 REVIEW_BASE 留空。

REVIEW_BASE="${REVIEW_BASE:-}"   # from --base <rev>; empty = detect from the upstream

if [ -n "$REVIEW_BASE" ]; then
  # Explicit base: must resolve to a commit — never fall back silently.
  # `--end-of-options` keeps a value starting with `-` from becoming an option;
  # DIFF_BASE is the resolved SHA, so the commands below never see raw input.
  if DIFF_BASE=$(git rev-parse --verify --quiet --end-of-options "${REVIEW_BASE}^{commit}"); then
    BASE_LABEL="$REVIEW_BASE"
  else
    echo "ERROR: --base '${REVIEW_BASE}' does not resolve to a commit in this repository" >&2
    DIFF_BASE=""
  fi
else
  # Base branch: prefer the tracked upstream's short name, fall back to `main`.
  BASE=$(git rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null | sed 's|.*/||')
  BASE="${BASE:-main}"
  DIFF_BASE="origin/${BASE}"
  BASE_LABEL="$BASE"
fi

# Current branch + head SHA
HEAD_BRANCH=$(git branch --show-current)
HEAD_SHA=$(git rev-parse --short HEAD)

# The three artifacts the review needs
if [ -n "$DIFF_BASE" ]; then
  git diff --stat "${DIFF_BASE}...HEAD"    # summary of what changed
  git diff "${DIFF_BASE}...HEAD"           # the actual diff
  git log "${DIFF_BASE}..HEAD" --oneline   # the commit trail
fi
[ -n "$DIFF_BASE" ]   # block exit status: non-zero when --base did not resolve

如果提供了 --base 但无法解析，请向开发者报告错误并停止——不要用上游分支替代。如果 diff 为空，请告知开发者“相对于 <BASE_LABEL> 没有更改——无需审查”，然后停止。仅在默认模式下：如果 origin/${BASE} 不存在（全新克隆、缺少远程），则回退到 git merge-base main HEAD 并以此为基础进行 diff；在摘要中注明使用了回退方案。三点 diff 会与合并基础版本进行比较，因此，若显式指定的基础版本是 HEAD 的祖先（计划的起始提交），则会准确得到自该版本以来所做的提交。

---

第 2 步 — 编写提示词（基础提示词 + 扩展）

评审方法位于 prompt.md 中——与 CI 操作随附的提示词完全相同。将其读入上下文，作为基础提示词。

然后按以下优先顺序查找仓库专属扩展（以第一个匹配项为准；其余项忽略）：

1. .review/extension.md（推荐约定，与运行时无关）
2. .github/ai-diff-reviewer/extension.md（适用于更倾向于将 .github/ 与工作流文件放在一起的团队的备用路径；为兼容 v1.5 之前的技能名称，也接受 .github/ai-pr-reviewer/extension.md）

如果找到匹配项——读取该文件，将其内容原样追加到基础提示词，然后跳到第 3 步。

如果没有找到匹配项：

• 如果 .review/.skip-bootstrap 存在 → 开发者之前选择不接受引导邀请。仅使用基础提示词（不作说明），跳到第 3 步。
• 否则 → 前往第 2.5 步（首次引导邀请）。

用一行说明组合后的配置，例如： 正在评审 feat/foo (a1b2c3d)，以 main 为基准。基础提示词 + .review/extension.md。 （使用 --base 时，注明修订版本：… 以 5c1eef0 为基准（--base）…）。

最终组合后的提示词将决定评审内容——包括严重性定义、“不要评论什么”的规则以及输出格式。

---

第 2.5 步 — 提供创建扩展的选项（仅首次）

只有在第 2 步未找到扩展文件且不存在 .review/.skip-bootstrap 标记时，才会执行此步骤。这是技能向开发者介绍扩展约定的唯一时机。记录回答后（无论是生成扩展内容还是选择退出标记），除非开发者删除标记，否则此仓库中的技能永远不会再次询问。

向开发者提出一个问题：

未在此仓库中找到 .review/extension.md。

我可以立即使用随附的默认提示词运行评审——它能发现约 90% 的通用问题（SQL 注入、未处理的 promise、缺少输入验证、明显的性能回归等）。

但它会漏掉仓库专属的问题：你的资金处理约定、禁止使用 console.log 的模块、RFC-014 模式，以及与你的架构相关、始终属于严重问题的 SQL 模式。这正是 .review/extension.md 的作用——针对此代码库编写、以文件为依据的严重性覆盖规则。

现在要创建一个吗？（约 30 秒的探索过程 + 一个约 100 行、包含具体覆盖规则的文件。）

• yes — 我会调用 generate-extension 子技能，然后返回并使用新生成的扩展运行评审。
• no — 这次仅使用基础提示词运行评审。下次技能激活时我会再次询问。
• never — 在此仓库中不再询问。我会创建 .review/.skip-bootstrap（一个已跟踪的 0 字节标记）。提交它，即可让整个团队采用相同偏好。若要重新启用此选项，请删除该标记。

处理回答：

• yes → 以扩展模式调用 generate-extension 子技能（参见 generate-extension/SKILL.md）。子技能完成 .review/extension.md 的写入后，从头重新进入第 2 步——刚写入的文件会被找到并叠加到基础提示词上。不要跳过子技能的探索阶段（12 次以上工具调用）；其价值就在于此。
• no → 使用基础提示词跳到第 3 步。不要保存任何内容。下次仍会再次询问。
• never → 运行：

  mkdir -p .review
  touch .review/.skip-bootstrap
  

  然后仅使用基础提示词跳到第 3 步。建议开发者提交该标记：git add .review/.skip-bootstrap && git commit -m "chore(review): opt out of AI Diff Reviewer bootstrap offer"。

如果开发者的回答不明确，默认选择 no（尽量减少干扰的选项）——不要在未告知的情况下替他们选择退出。

---

第 3 步 — 执行评审

使用编码 Agent 自带的工具（Read、Grep、Glob），将组合好的提示词应用于差异：

• 提示词要求你使用 read_file / grep / glob — 将这些映射为运行环境提供的相应原语。完整读取已更改的文件；仅看差异通常不足以了解上下文。
• 提示词要求你使用 post_inline_comment(path, line, body, severity) — 由于你是在本地运行，没有 GitHub 写入权限，因此请将每条发现收集到内部列表中，记录格式为 {path, line, severity, body}，并在第 4 步将它们打印为表格。
• 提示词要求你恰好一次调用 submit_review(summary) — 这表示评审已完成。到达此处时，打印最终摘要并停止。

**成本控制：**将轮数限制在 CI 操作执行的相同数量（约 25 轮），内联评论数量上限也保持相同（默认 20 条）。不要对所有内容进行 grep；只搜索你要评论的文件及其导入项。

---

第 4 步 — 打印评审结果

按照 CI 机器人在 PR 上发布的相同格式在终端输出评审结果 — 这是保持一致性的约定：

## Verdict
<one sentence — "Looks good", "Blocking security fix needed", etc.>

## Findings

| # | Severity | File | Summary |
|---|----------|------|---------|
| 1 | 🚨 critical | `src/auth.ts:55` | SQL injection in raw-string login query |
| 2 | ⚠️ warning  | `src/cache.ts:120` | Unbounded cache key cardinality |
| 3 | ℹ️ info     | `tests/utils.ts:12` | Helper could be reused from existing fixture |

### 1. `src/auth.ts:55` — 🚨 critical
<the full finding body — 2-4 sentences + optional ```suggestion block```>

### 2. `src/cache.ts:120` — ⚠️ warning
<...>

### 3. `tests/utils.ts:12` — ℹ️ info
<...>

## Notes (no inline anchor)
- <cross-cutting concerns, architecture, test-strategy comments>

**Recommendation:** approve / request-changes / comment-only

**建议不等于检查结果。**在 CI 上，GitHub 检查由运行时的严格度门槛决定；即使模型建议 approve，检查仍可能失败 — 在增量评审中，模型认为已修复的先前发现仍可能尚未解决。因此，v2.3.1+ 的 CI 评审会以运行时写入的 > **Check status: …** 区块结尾，跟踪评论中的 **Strictness gate:** 行始终具有权威性。切勿仅凭建议行就报告评审“已通过”；apply-review 第 2f 步介绍了如何判断实际结果。

复现这一精确格式（判定 → 发现表格 → 每条发现的正文 → 备注 → 建议），才能让开发者相信两种界面采用了相同的方法和严重程度模型。在 CI 的某次生成的第 2 轮及后续轮次中，Iteration-Aware Review 还可能会对本地完整评审仍会列出的发现进行去重 — 这种差异是预期行为，并非一致性缺陷（参见上文的 仅 CI 适用的界面）。

**可选的后续步骤提示。**当评审结果干净（没有 🚨 严重或 ⚠️ 警告发现），或者开发者明确表示已准备好推送时，请在输出末尾添加一行指向同级子技能的提示：

Next step: want me to open the PR? — I can draft the title + body from
this same diff (see the `open-pr` sub-skill). Or run `gh pr create`
yourself.

如果评审发现了阻塞问题，请勿打印此提示 — 先修复，再发布。

---

第 5 步 — 扩展文件约定（供使用者参考）

创建扩展文件有三种有效方式：

1. 自动初始化 — 在全新仓库中说“评审我的分支”，并在第 2.5 步的提示中回答是。generate-extension 子技能会执行包含 12 次以上工具调用的 Discovery，并为你写入 .review/extension.md。这是最简单的方式 — 推荐用于首次设置。
2. 显式调用子技能 — 说“为此仓库生成一个 .review/extension.md”（或使用 Activation 中列出的其他触发语）。结果与（1）相同，但会跳过初始化提示。可用于重新生成或优化现有文件。
3. 手动编写 — 使用下方的架构和示例自行创建文件。适合清楚自己需要哪些覆盖项，且不需要 Discovery 指引的情况。

无论选择哪种方式，布局选项都相同：

选项 A — .review/extension.md（推荐）：

my-repo/
├── .review/
│   └── extension.md         ← auto-detected by this skill
└── .github/
    └── workflows/
        └── pr-review.yml    ← CI workflow uses the same file

选项 B — .github/ai-diff-reviewer/extension.md（如果你更希望将文件放在工作流旁边，则可用此备用路径）。旧版 v1.5 之前的路径 .github/ai-pr-reviewer/extension.md 仍受识别，以保持向后兼容。

在 CI 工作流的 prompt-extension-file: 输入中引用同一个文件，即可确保本地与 CI 完全同步：

# .github/workflows/pr-review.yml
- uses: DailybotHQ/ai-diff-reviewer@v3
  with:
    api-key: ${{ secrets.ANTHROPIC_API_KEY }}
    github-token: ${{ secrets.GITHUB_TOKEN }}
    prompt-extension-file: .review/extension.md   # same file the skill auto-detects

.review/extension.md 示例：

## Severity overrides for our codebase

- Any `SELECT * FROM users` in a request path is **critical** (PII exposure).
- Missing `AbortController` on a `fetch()` in `apps/frontend/` is **warning**
  (React 18 pattern we standardized on in RFC-014).

## Don't comment on

- Formatting in `apps/legacy/*` — that module is scheduled for a rewrite.
- Missing tests in `experiments/` — that folder is intentionally exploratory.

完整的编写指南（结构、技巧和完整示例）： docs/PROMPTS.md。

---

备注

• **该技能会运行你的本地 Agent，不会调用单独的大模型。**如果你的运行环境是 Cursor，且使用 auto，审查费用会计入你的 Cursor Pro 订阅。如果你的运行环境是 Claude Code，并使用 API 密钥，费用则以 Anthropic 代币计费。无论哪种情况，如果你本来就打算使用 Agent，那么本地审查就是一项“免费赠送”。
• **与 CI Action（流程 B）配合使用时，该技能不会取代它。**CI Action 仍会在每个 PR 上运行，并发布权威审查结果（行内评论、严重程度门槛、阻止合并）；该技能适用于“推送前”的环节。在流程 A（仅本地）中，本地技能就是整个审查流程——没有 CI 阶段，也没有推送后的权威审查；发现的问题只会显示在你的终端中，你可以在创建 PR 前自行决定如何处理。
• **扩展内容的一致性由你负责，工具不会强制执行。**如果你的 .review/extension.md 与 CI 工作流的 prompt-extension-file: 指向的内容不同，就会产生偏差。请让它们使用相同的路径。
• **退出选项标记（.review/.skip-bootstrap）。**这是一个已跟踪的 0 字节标记文件，它会告诉该技能：“不要再提议在此仓库中初始化扩展——团队知道有此选项，并决定继续使用基础提示词。”在第 2.5 步的提示中回答 never 即可创建该文件。删除该文件即可重新启用此选项。按预期应提交此文件，让整个团队使用相同的体验。
• 可添加到入门模板中的错误报告、功能请求和扩展模式： github.com/DailybotHQ/ai-diff-reviewer/issues。