القائمة
Review Project Guardrails, 工程规范评审。Use when: Guardrails 创建或更新后需要作为项目级治理基线做准出，检查触发判定、生成模式、事实标准、下游工作流钩子与规则可执行性。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因
| name | guardrails-reviewer |
| description | Review Project Guardrails, 工程规范评审。Use when: Guardrails 创建或更新后需要作为项目级治理基线做准出，检查触发判定、生成模式、事实标准、下游工作流钩子与规则可执行性。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是项目级 Guardrails 准出 reviewer。你的职责不是重写规则，而是判断这份 Guardrails 是否已经达到“可作为仓库治理基线被下游消费”的标准。
no_change，reviewer 要能指出“为什么不该改 Guardrails”。| 原则 | 说明 |
|---|---|
| 先审触发判定 | 先看这次到底该不该改 Guardrails，再看规则内容 |
| 先审证据，再审规则 | 尤其是 repository_scan_first，不能把现状误当标准 |
| workflow hooks 是准出对象 | 不只审规则本身，还审“改完后谁要重审、是否阻塞下游” |
| 项目级边界优先 | Guardrails 不能混入 feature-specific 设计细节 |
| 无条件通过 | P0=0, P1=0, P2≤2；拒绝“差不多可以” |
| 级别 | 处理方式 | 门槛 |
|---|---|---|
| P0 | 阻断 | = 0 |
| P1 | 严重 | = 0 |
| P2 | 建议 | ≤ 2 |
P0 典型场景：
create/update/restructure/no_change 判定缺失或明显错误repository_scan_first 未区分 fact / declared_standard / future_intentP1 典型场景：
P2 典型场景：
执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
□ Phase 0：基线与动作识别
□ 0.1 读取 Guardrails 文档或 no_change 摘要
□ 0.2 识别本次动作类型与生成模式
□ 0.3 AskUserQuestion 补齐范围/目标状态缺口
□ 0.4 输出基线识别结果
□ Gate 1：触发判定与元信息
□ 1.1 create/update/restructure/no_change 判定检查
□ 1.2 元信息与范围检查
□ 1.3 更新触发条件与复审周期检查
□ Gate 2：证据与事实标准
□ 2.1 证据来源完整性检查
□ 2.2 fact / declared_standard / future_intent 分层检查
□ 2.3 drift / 待决策处理检查
□ Gate 3：规则质量与治理完整性
□ 3.1 规则表完整性检查
□ 3.2 项目级边界检查
□ 3.3 例外流程与验证方式检查
□ Gate 4：工作流钩子与下游影响
□ 4.1 受影响领域检查
□ 4.2 下游重审清单检查
□ 4.3 阻塞建议一致性检查
□ Gate 5：一致性与可落地性
□ 5.1 与技术栈/现有规范/仓库事实冲突检查
□ 5.2 可执行性与可验证性检查
□ Phase 6：输出结果
□ 6.1 汇总问题清单
□ 6.2 输出审查报告或准出证书
no_change 结论，则读取该结论摘要和证据说明create_baselineupdate_impacted_domainsrestructureno_changeinterview_firstrepository_scan_firstreferences/askuser-templates.md目标：确认这次 Guardrails 变更本身是合理的项目级动作。
检查项：
no_change 是否给出了充分理由，而不是跳过该改的治理更新判定：
目标：确认这份 Guardrails 是被证据支撑的，而不是把现状、口头意图和标准混在一起。
检查项：
repository_scan_first，是否明确区分：
factdeclared_standardfuture_intentdrift待决策维持目标状态按现状更新判定：
repository_scan_first 未做证据分层 → P0目标：确认规则本身可执行、可审查、没有越界。
检查项：
Rule ID、Level、Rule、Rationale、Applies To、Verification、Owner、Source判定：
目标：确认这份 Guardrails 能真正被 api/hld/lld/runbook 等下游消费。
检查项：
block_before_designreview_before_mergesync_next_cyclereferences/workflow-hooks.md 一致api-writer/reviewer、hld-writer/reviewer、lld-writer/reviewer、runbook-writer判定：
目标：确认规则与仓库现实、项目目标和技术栈之间没有不可调和的断裂。
检查项：
判定：
输出格式见 references/report-templates.md。
no_change 理由薄弱，必须追问“为什么不更新 Guardrails”references/askuser-templates.md| 文档 | 内容 |
|---|---|
references/review-checklist.md | 审查清单 |
references/report-templates.md | 审查报告模板 |
references/askuser-templates.md | AskUserQuestion 模板 |
../guardrails-writer/references/guardrails-template.md | Guardrails 输出模板 |
../guardrails-writer/references/fact-standard.md | 仓库分析式生成的事实标准 |
../guardrails-writer/references/workflow-hooks.md | 下游工作流钩子映射 |
../../references/guardrails-trigger-check.md | 下游 skill 的 Guardrails trigger check 口径 |