ben2pc Reviewer Creator
为 deep-review 创建项目级审查者。产物写入规则适用的仓库根或子包 docs/rules/review/<name>.md，由 deep-review 自动发现。
什么时候使用
- 项目有内置审查维度未表达的专属规则；
- 某个内置维度需要结合项目架构、平台或业务进一步收窄；
- 用户显式调用
/reviewer-creator。
通用检查已经被内置审查者覆盖、且没有项目专属判断时不要创建文件。
读取当前协议
创建前读取同一插件 deep-review 的风险标签、项目审查者元数据协议和路由表，再按需要读取相关宿主；这些部分是当前协议的唯一信息源，无需读取其余正式评审流程。 每个项目审查者必须显式选择一种定位：
- 补充内置维度：写
extends: <内置名>，与宿主在同一干净上下文内执行，不额外占用审查代理。 - 全新独立维度：写
extends: standalone，仅当当前内置维度确实都不承担最终判断责任时使用。
不要省略 extends 让调度器猜测正文语义。新建的 name 避免与内置名称重名；历史同名项按共享协议兼容，不为命名风格迁移合法规则。
流程
1. 收集规则来源
读取用户给出的规则、适用路径和例外，再搜索仓库已有规范与相关代码。优先引用可验证的项目事实，不把口头偏好扩写成通用最佳实践。只有判断边界不明显时才补充具体例子。
2. 选择宿主与触发条件
根据规则的最终判断责任选择最接近的宿主；不是按文件类型机械选择。仓库证据足够明确时直接确定定位和触发条件；只有会改变 extends 或路由结果的真实歧义才询问用户确认。
触发条件要描述差异中的事实或风险表面。always 只用于几乎所有正式拉取请求都必须检查的项目契约。
3. 设计检查清单
保留足以让审查模型稳定执行的细节：
- 具体、可判断的审查问题；
- 检测表，说明差异出现什么信号时关注什么；
- 每条发现所需证据和影响；
- 判断边界容易混淆时，提供真正有区分度的“应报告”或“不应报告”场景。
检查问题和场景数量由项目规则复杂度决定，不为填满模板制造内容。不要把固定行数、固定次数或个人风格写成缺陷；确有阈值时说明它来自哪个项目预算或规则。
4. 写入文件
用 git rev-parse --show-toplevel 定位仓库根，非 git 仓库回退当前目录。按规则适用范围选择仓库根或对应子包的 docs/rules/review/，与发现路径一致；范围明确时直接选择，只有跨作用域责任不清时询问。按 模板 写入所选目录的 <name>.md。正文用项目对话语言，frontmatter 键保持模板格式。所有项目审查者都继承主代理数据包中的统一 Reviewer Output Contract，不得改变核心章节或列。补充型审查者删除模板里的维度输出要求，继承宿主审查者的输出契约并由主编排追加项目来源；只有 extends: standalone 保留该节，用于补充本维度在单元格中必须说明的证据。
5. 验证
有现成协议校验器或相关测试时运行；没有时解析 YAML frontmatter，按共享协议检查必填与可选字段、合法宿主、触发标签及工具权限，并验证引用路径、命令和适用边界样例。不要为了创建一个规则搭建测试框架。工具申请默认 [Read, Grep, Glob]，确需只读验证才加 Bash；实际权限仍取主编排策略与运行时限制的交集。
返回文件路径、定位、触发条件和验证证据。
Anti-patterns
- 用一个全新审查者重复内置检查，制造同一行的重复发现。
extends缺失或非法，期待主调度器读取正文猜宿主。- 为了减少代理数量，把真正独立的治理维度硬塞进不相关宿主。
- 检查清单只有“是否符合最佳实践”之类抽象问题。
- 把安全利用风险写进结构质量审查，或反过来只检查插件 schema 而漏掉执行能力。
- 未验证 frontmatter 和触发条件就宣称创建完成。