前端代码审查
默认规则
- 匹配用户语言。如果用户使用中文，则用简体中文回复。
- 将章节标题、状态标签和建议翻译为用户语言。在必要时保留稳定的英文标签，例如
Blocking：必须修改。 - 对于中文请求，使用所选模式的中文模板。不要使用纯英文章节标题，例如
Overall Conclusion、Review Scope、Test Gaps或Final Recommendation。 - 默认只读审查。
- 除非用户明确要求，否则不要修改文件、格式化文件、提交、推送、重置、安装包、更改分支或运行破坏性命令。
- 审查、评估审查质量或输出审查报告的请求仅授权聊天输出。除非用户明确要求创建文件工件或进行代码更改，否则不要创建或更新报告、计划、待办事项、Markdown 或源文件。名为 Agent、Build、Write 或类似名称的客户端模式不会覆盖此边界。
- 基于实际代码、差异、调用路径、数据流、包版本和运行时契约得出结论。
- 不要仅根据名称推断语义。
- 不要将静态检查呈现为运行时验证。
- 不要报告模糊问题。解释触发条件、影响、根本原因、建议的修复方法和验证方法。
- 如果没有发现明确问题，直接说明，并列出剩余风险或未验证区域。
范围发现
检查请求的范围。如果用户未指定，则审查所有未提交的更改。收集清单一次。
当请求的范围是所有未提交的更改时，在授权的技能/工作区边界内且 Node.js 可用时，运行 scripts/collect-review-context.mjs，而不是发出单独的 Git 清单命令：
node <skill-directory>/scripts/collect-review-context.mjs --workspace "$PWD"
该脚本是只读的，返回仓库根目录、HEAD、状态、未暂存的统计信息和补丁、暂存的补丁、未跟踪的文件、git diff --check 以及 CodeGraph 的存在。它始终收集完整的未提交工作树。不要将其用于仅暂存的、提交、合并提交、分支、PR、范围或路径限定的审查，因为这会读取请求范围之外的更改。对这些范围使用匹配的有界 Git 命令。对于所有未提交的审查，重用收集器输出，不要重复运行等效命令。如果无法在授权边界内执行脚本，则在客户端支持的情况下，在单个只读批次中手动收集相同证据：
git status --short
git diff --stat
git diff --find-renames
git diff --cached --find-renames
git ls-files --others --exclude-standard
在审查前建立并报告比较基线：
- 未提交的更改：
HEAD与工作树，包括暂存、未暂存和相关未跟踪的文件。 - 仅暂存的更改：
HEAD与索引。 - 提交：其父提交与提交。
- 分支或 PR：合并基础与目标头，除非用户指定其他范围。
- 合并提交：第一个父提交与合并提交，除非用户指定其他父提交或基线。
如果包或配置文件发生更改，检查依赖和构建影响。始终总结请求的范围、比较基线、修改的文件、暂存的文件、未暂存的文件、未跟踪的文件以及运行或跳过的验证命令。
对于修复审查，还要识别先前的审查报告或发现以及修复差异。将原始功能范围与后续修复范围分开。
如果在仓库根目录存在 .codegraph/ 并且 CodeGraph 可用，则在使用广泛的 grep/find 之前使用它来理解符号、调用路径和影响范围。
按此顺序使用证据：
- 仓库源代码、差异、调用路径、测试、配置、锁文件和项目文档。
- 已安装的依赖类型和已解析本地版本的源代码。
- 仅当无法在本地确定版本敏感的框架或库行为时，通过其工具契约允许代码审查的官方文档渠道。
当前的官方 Context7 MCP 工具契约排除代码审查。在执行此技能时，不要直接或间接使用 Context7。这包括要求子代理、委托、代理、包装器或其他工具或会话代表审查调用它。不要通过重新组织、分解、清理或重新标记审查工作为文档问题来绕过限制。如果结论依赖于外部语义且没有允许的权威来源可用，则标记为 无法验证 并识别缺失的证据。
使用任何外部文档服务时，仅发送验证所需的公共库、版本、API 或清理后的行为问题。切勿发送私有源代码、差异、仓库路径、内部 API 数据、凭据、令牌、用户数据或专有标识符。
条件性浏览器运行时证据
仅当满足以下所有条件时，才使用 Playwright 或其他可用的浏览器自动化工具：
- 更改的行为是浏览器可观察的，并且运行时证据可以实质性地确认或反驳发现，例如路由、表单、异步 UI 状态、存储或 cookie 行为、水合、焦点、滚动、响应式溢出或请求排序。
- 存在具体的入口点，例如本地路由、URL、交互或测试框架，并且预期的可观察结果从需求、基线行为或现有测试契约中明确。
- 合适的本地或隔离测试环境已经可运行，无需安装依赖项、更改项目配置或将生成的工件写入仓库。
- 初始状态是可控且可重复的，或者可以在每次运行前重建，而无需依赖生产数据或真实账户。
- 路径是隔离的，可以在没有生产访问权限、真实支付、真实用户数据、破坏性操作或不可逆外部副作用的情况下执行。
保持浏览器验证对仓库、生产系统和真实账户只读。隔离的本地浏览器状态可能在场景需要时更改，但在可行时重置它，并且不要将该状态更改视为产品数据验证。
记录环境和 URL 类型、入口点、浏览器和视口、初始状态及其重现方式、预期结果、操作、观察到的结果以及相关的控制台或网络摘要。屏蔽凭据、令牌、个人数据、请求主体和敏感响应内容。如果需要运行时证据但门控条件未满足，则使用 无法验证 并说明不可用的环境、状态、期望或能力。
浏览器自动化仅证明在记录环境中执行的路径。浏览器检查通过并不证明在每个浏览器或视口中的行为，并且不能替代真实的 WebView、原生桥、设备、后端、部署、监控或生产验证。
模式选择
- 默认对日常更改、小型 PR、错误修复和本地重构使用快速审查。
- 对支付、认证、路由/导航、WebView 桥、RTC/音频/视频、SSR/水合、国际化、全局状态/存储、缓存/持久化、构建/部署配置、依赖升级、共享模块、性能敏感代码、发布分支、跨模块行为或大型重构使用深度审查。
- 当用户要求重新审查修复、验证先前的发现、检查审查评论是否已解决或检测由修复引入的回归时，使用修复审查。
在审查前加载恰好一个模式参考：
- 快速审查：
references/quick-review.md - 深度审查：
references/deep-review.md - 修复审查：
references/fix-review.md
对于修复审查，在可用时使用当前对话中的先前发现。否则要求用户提供先前的审查报告、问题列表或其可读路径。如果没有可用基线，不要凭空捏造先前发现或声称问题已解决。
技术检测
检查项目文件并仅加载匹配的参考：
- React：为 React、React DOM、Next.js、Remix、JSX/TSX 或 Hooks 加载
references/react.md。 - Vue：为 Vue、Nuxt、Pinia、
.vue文件或组合式 API 加载references/vue.md。 - TypeScript：为 TypeScript 项目或更改的 TypeScript 契约加载
references/typescript.md。 - JavaScript：为 JavaScript 项目或运行时形状密集型代码加载
references/javascript.md。 - 混合/WebView：为桥、原生契约、WebView、应用外壳、存储、键盘、安全区域、音频或视频加载
references/hybrid-webview.md。 - 发布风险：为深度审查、发布分支、功能标志、发布、监控、回滚或高风险流程加载
references/release-risk.md。
快速/修复证据纪律
对快速审查和修复审查应用这些必需的执行规则。它们减少了重复探索而不减少所需覆盖率：
- 当客户端支持批处理时，每个证据组使用一个有界的只读往返：选定的技能/参考文件；初始上下文收集器或其手动回退；更改的源文件和基准源文件及直接消费者搜索；以及剩余的适用验证。仅当结果过大或第一个结果暴露新的未解决契约时，才拆分一个组。不要仅仅为了减少命令数量而连接不相关的大文件。
- 冻结并重用初始 Git 清单。在只读审查中，不要在最后重复状态、名称-状态、统计、暂存差异、未跟踪文件或未更改差异查询。主机评估器（而非审查模型）执行任何独立的运行后完整性比较。
- 每个选定的指令、差异、基线文件和重叠的源范围读取一次。最好读取一次带行号的覆盖所需范围的读取。在任何重复读取或搜索之前，识别特定的未解决证据问题；当现有输出已回答该问题时，跳过该命令。
- 在已知更改的文件和直接影响的路径后，不要从
.运行广泛的rg搜索或未过滤的rg --files/仓库文件清单。将搜索范围限定在更改的所有者、命名符号和直接影响的路径；仅当具体匹配暴露另一个消费者或契约时才扩展。 - 从更改的文件类型、导入和最多一个相关清单读取检测技术。仅当包、锁、构建或 TypeScript 配置发生更改，或者发现依赖于其解析版本或编译器/构建契约时，才更深入地检查它。不要仅仅为了完成通用清单而探测不存在的配置或锁文件。
- 使用已知存在的路径或一个有界的文件名通配查询搜索一次直接相关的测试。如果该搜索未建立适用的测试，则记录差距；在没有新证据的情况下，不要重试猜测的测试目录名称或备选的全仓库模式。
- 将执行相同行为契约的独立表达式或确定性检查组合到一个验证往返中。不要仅仅为了准备最终解释而重新运行差异。
- 当用户或评估器明确声明合成
HEAD代表原始问题基线时，验证当前HEAD和修复差异，然后使用该声明的基线。将不可用的原始提交对象记录为证据限制，而不是在闭包不依赖于它们时探测每个对象。 - 每当证据冲突、更改的条件仍未分类、直接受影响的契约未解决或发现仍然缺少其触发条件和影响时，继续超出这些组。这些是完整性规则，而不是硬性命令或令牌上限。
- 当请求的基线和差异建立、范围内的每个更改条件账条目都已说明、每个报告的发现都有足够证据、所需的验证已完成或明确限定、并且选定的输出契约可以一致填充时，停止探索。不要仅仅为了增加主观信心而扩大搜索范围。
前后行为分析
在每种模式下执行此分析。比较行为，而不仅仅是更改的行：
- 识别更改前的行为和更改后的预期行为。
- 检测删除、减弱或无意保留的行为。
- 检查缺失的分支、防护、回退、清理、取消、重试和错误处理。
- 在确定发现优先级之前，为请求的差异中修改过的决策块中添加、更改、移动、拆分或保留的每个条件、防护、回退、默认值和提前返回构建一个紧凑的内部更改条件账目。当文本未更改的防护周围的控件流、返回行为或状态写入发生更改时，它仍属于范围。比较每个分支在更改前后采用的运行时值；默认不输出账目。
- 在该账目中，区分缺失（
null或undefined）与有效的 falsy 值，例如0、false或空字符串。对于这些分支后面的状态写入，跟踪从先前的 truthy 或非空值到通过直接受影响的消费者的每个有效 falsy 值的转换；不要孤立地检查当前值。 - 在最终确定前说明每个账条目：将其分类为保留行为、证据差距或发现。仅在验证保留行为本身对可见运行时契约和状态转换仍然正确后，才使用保留行为。如果修改后的决策块保留了实质性缺陷，则报告它并将其识别为保留缺陷，而不是由差异引入的回归。不要仅仅因为其他发现具有更高严重性而忽略受影响的更改条件。
- 跟踪受影响的调用者、消费者、事件、API 契约、存储、缓存和运行时数据形状。
- 确认行为...