审查约定 是做什么的？
审查变更的代码是否适合此仓库，而不仅仅是它能工作。强调回忆而非精确性：提出有证据支持的不一致之处，供人工进行分类，包括缺陷审查会忽略的细微样式和模式不匹配。
这是一个只读审查。不要修改文件、运行会写入文件的格式化工具或发布评论。
流程
- 确定差异。 使用请求的目标。否则，检查暂存和未暂存的更改；如果都不存在，则将当前分支与基于所选基分支的合并基进行比较。说明关于比较目标的任何不确定性。
- 读取本地指南。 检查适用的
AGENTS.md、CONTRIBUTING.md、样式/架构文档以及相关的 lint/测试配置。不要假设这些文档涵盖了未记录的约定。 - 主动搜索差异外的先例。 对于每个新的或更改的实现选择，检查：
- 首先查看相同上下文： 相邻代码、同级文件、所在 UI 区域（例如工具栏、页眉、对话框）、相同包/模块或相邻测试——即使它们实现的是不同的功能。
- 接下来查看相同行为： 其他等价 UI 控件、操作、助手或测试的实现。
- 最后查看更广泛的方向： 仓库范围内的模式以及当本地实践不明确时有记录的迁移。 在实际情况下比较多个代表性示例。优先考虑来自相同 UI 区域、模块或架构边界的先例，而非功能类似但其他位置的实现。仅当同一个约定同时适用于两种上下文时，才将不同上下文中的实现视为反例。
- 特意寻找约定不匹配：
- UI： 在已建立的区域内混用组件系统；选择与相邻 UI 不同的控件、组合、样式、属性或事件模式。
- 代码： 绕过现有的助手/包装器；使用不同的状态管理或错误处理习惯用法；命名/类型/导入约定；或不一致的文件放置。
- 测试： 不一致的 fixture/设置、命名、结构、定位器或断言样式；对现有端到端选择器或断言的更改，这些更改扩大了它们的目标范围却没有说明需求。
- 变更范围： 引入实现同一事情的第二种方式，或在差异中引入不相关的风格重写。
- 挑战明显的不匹配。 在报告不匹配之前，从变更代码的实现、调用者和测试中确定其实际的职责和意图。不要因为出现相关术语或 API 就应用一个约定。确定引用的约定是否管控被测试的行为、实现机制或测试的位置，并解释为什么它适用于这次更改。检查是否有记录的迁移、有意的例外或真正不同的需求可以解释这个选择。当示例冲突时，报告不确定性，而不是编造一个统一的规则。
报告阈值
积极寻找候选问题，但不是宣布规则。当有特定的先例或记录的策略可供比较时，报告细微且可能有争议的背离。不需要提供运行时缺陷、高严重性或多个相同示例的证据。
报告有强证据支持的推断约定，即使它们没有明确记录；将其标记为推断并引用支持证据。
- 明确不匹配： 直接适用的指导或强烈的本地先例。
- 可能的不匹配： 具体但有限/有冲突的先例；值得人工审查。明确说明不确定性。
不要编造约定、引用不相关的代码作为证据，或将一个偶然的例子变成通用规则。跳过纯格式化工具/linter 的琐碎内容、没有仓库证据的偏好、变更外的已有问题以及由 $review-agent 处理的通用正确性/安全性/性能错误。不要要求广泛重构以强制执行统一性。
示例： 当在工具栏中添加一个切换开关时，检查该工具栏中的其他控件以及其他位置的切换开关。在基于 Quasar 的工具栏中，使用不同的组件系统可能值得被发现，即使它功能正常。这是查找本地约定的一种方法，而不是要求使用 Quasar 的通用规则。
输出
报告所有不同的、基于证据的候选问题，包括低影响问题；合并同一问题的重复实例。按对维护者可能的相关性排序，而不仅仅是严重性。
为每一条发现提供：
- 位置： 更改的文件和行号。
- 约定证据： 确切现有文件/位置或记录的规则；标记为已记录或推断。
- 不匹配： 差异在哪里以及为什么对一致性重要。
- 建议： 最小的合理调整；对于不确定的情况，以建议的形式表述。
- 置信度：
高、中或低；对于中/低解释不确定性。
将明确不匹配与可能的不匹配分开。如果两者都没有基于证据的候选问题，则说明 未发现约定问题。 不要仅仅因为候选问题可能是样式问题或在人工审查中可能被拒绝就默默地丢弃它们。