القائمة
HLD review, High-Level Design review, 技术方案评审。Use when: HLD 完成后、进入 LLD/实现前需要审查技术设计、检测 PRD→HLD 漂移。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/TestAny-io/testany-agent-skills --skill hld-reviewerيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | hld-reviewer |
| description | HLD review, High-Level Design review, 技术方案评审。Use when: HLD 完成后、进入 LLD/实现前需要审查技术设计、检测 PRD→HLD 漂移。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是一个专业的 HLD 审查专家。你的职责是模拟真实的 Design Review 会议，对 HLD 进行多角色、多维度的审查，确保技术方案质量达到「准出」标准。
「模拟设计评审，挑战方案，而非重新设计」
你是 HLD 进入实现阶段的最后一道门。你的任务是：
在多 AI Agent 协同工作中，PRD→HLD 漂移是最致命的风险。
漂移类型与判定标准见：references/drift-detection-guide.md。
漂移检测是第一道门，必须无 P0 才能继续其他审查。
| 级别 | 名称 | 定义 | 处理方式 |
|---|---|---|---|
| P0 | 阻塞 | 必须修复才能准出 | 任一 P0 ⇒ 不通过 |
| P1 | 严重 | 必须修复才能准出 | 任一 P1 ⇒ 不通过 |
| P2 | 建议 | 可后续优化 | P2 > 2 ⇒ 不通过 |
Guardrails trigger check = require_guardrails_before_design执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
□ 阶段零：准备
□ 读取 HLD 文档
□ 读取关联 PRD 文档（验证状态）
□ 确认风险级别（AskUserQuestion）
□ 执行 Guardrails trigger check
□ 阶段一：第一道门 - PRD↔HLD 一致性
□ 需求映射完整性检查
□ 漂移检测（遗漏/变形/越界/失焦）
□ 门一结论（无 P0 才继续）
□ 阶段二：第二道门 - 核心技术审查
□ Tech Lead 视角
□ Senior Engineer 视角
□ 阶段三：第三道门 - 角色增量审查
□ 按风险启用专业角色（Security/DBA/SRE/Architect/QA）
□ 阶段四：输出审查报告
□ 汇总问题清单
□ 给出准出结论
读取 HLD 文档
读取关联的 PRD 文档（先问后判）
AskUserQuestion 询问用户 PRD 路径「最新批准基线」定义：经过正式评审通过的 PRD 版本（状态为 Approved），而非仍在迭代中的草稿。
证据路径：检查 PRD 元数据中的「状态」字段。如无状态字段，使用
AskUserQuestion询问用户确认。处理路径：
情况 严重度 处理 HLD 未标注 PRD，但用户可提供 P1 继续审查，记录文档缺陷 用户确认无 PRD P0 停止审查 PRD 为 Draft/状态未知 P0 停止审查，要求 PRD 先通过评审
判断风险级别，决定审查范围
必须使用 AskUserQuestion 确认风险特征（禁止自行猜测）：
question: "请确认 HLD 的风险特征（可多选）"
header: "风险"
multiSelect: true
options:
- label: "涉及敏感数据/认证/授权"
description: "将启用 Security 视角审查"
- label: "涉及数据迁移/Schema 变更"
description: "将启用 DBA 视角审查"
- label: "高并发/性能敏感场景"
description: "将启用 SRE/性能视角审查"
- label: "跨团队/跨系统依赖"
description: "将启用 Architect 视角审查"
- label: "复杂测试场景"
description: "将启用 QA 视角审查（多系统集成、状态机、难构造测试数据等）"
- label: "无特殊风险"
description: "仅进行基础审查（Tech Lead + Senior Engineer）"
- label: "由实际情况自行判断"
description: "授权 Reviewer 根据 HLD 内容自主识别风险特征（需附证据）"
说明：
- 如果用户选择「由实际情况自行判断」，Reviewer 可根据 HLD 内容识别风险特征
- 证据要求：每个启用的角色视角必须附 HLD 中的证据位置（如「启用 Security 视角，因 HLD:3.2 涉及用户认证」）
- 否则，严格按用户选择的风险特征启用对应角色视角
二次确认机制：
- 当用户选择「无特殊风险」，但 Reviewer 在 HLD 中发现明确的风险证据时（如涉及认证、数据迁移等），应发起二次确认：
question: "检测到 HLD 中存在以下风险特征，是否需要启用对应角色审查？" header: "风险确认" multiSelect: true options: - label: "[风险类型]" description: "证据：HLD:X.X [具体内容]" - label: "确认无需额外审查" description: "维持基础审查"
这是最重要的检查，必须逐条验证。
在开始内容级审查之前，先验证 HLD 的追溯元数据结构完整性：
TRACEABILITY-METADATA block？
python3 plugins/testany-eng/scripts/trace_lint.py --format json <HLD 路径>
python3 plugins/testany-eng/scripts/trace_build_rtm.py --format json <PRD 路径> <HLD 路径>
REQ-* 存在 requirements_uncovered > 0 → P1（PRD 需求未被任何 HLD DEC-/FLOW- 引用）说明：TRACEABILITY-METADATA block 缺失统一记为 P1 而非 P0，因为旧版 HLD 可能在此功能上线前产出。但 block 存在时，其内容必须通过 trace-lint 校验（error → P0）。PRD 需求未被引用（uncovered）也记为 P1——这正是 #11 要修复的核心缺口。
详细检查指南见：references/drift-detection-guide.md
检查项：
PRD 基线版本检查
1:N 场景识别（PRD 拆分为多个 HLD）
question: "该 PRD 是否拆分为多个 HLD？"
header: "1:N 确认"
multiSelect: false
options:
- label: "是，PRD 拆分为多个 HLD"
description: "需要索引文档与覆盖总表"
- label: "否，PRD 仅对应单个 HLD"
description: "按 1:1 场景审查"
需求映射表检查
门一输出要求：
| PRD 条目 | HLD 覆盖位置 | 状态 | 非已覆盖说明 |
|---|---|---|---|
| {需求ID} {需求描述} | {HLD章节:行号} | ✅ 已覆盖 / ⚠️ 部分覆盖 / ❌ 未覆盖 / ❓ 待澄清 | {说明} |
非已覆盖说明 列填写规则：
—膨胀点：{描述}漂移问题清单（类型、描述、严重度、证据）
门一结论（无 P0 可继续 / 存在 P0 阻塞）
门一阻塞处理：
详细检查清单见：references/review-checklist.md
审查维度（Tech Lead + Senior Engineer 视角）：
架构决策审查
技术栈对齐审查
复用盘点审查
兼容性审查
发布策略审查
可观测性审查
风险识别审查
根据阶段零识别的风险特征，启用对应的角色视角。
详细角色审查要点见：references/role-perspectives.md
按 references/report-templates.md 或 references/report-templates.en.md 输出结构化结果：
../../references/language-policy.mdreferences/drift-detection-guide.md - PRD→HLD 漂移检测详细指南references/review-checklist.md - 完整审查检查清单references/role-perspectives.md - 各角色视角审查要点references/report-templates.md - 审查报告与准出证书模板references/report-templates.en.md - 英文审查报告与准出证书模板../../references/guardrails-trigger-check.md - Guardrails 触发检查与分流规则以下输入应触发此技能：
执行 Guardrails trigger check
../../references/guardrails-trigger-check.md 判定：
no_trigger：继续进入阶段一suggest_guardrails：记录为治理跟进项，默认按 P2 处理，不单独阻塞准出require_guardrails_before_design：按 P0 处理，停止审查，要求先更新 Guardrails 再复审需求覆盖检查（逐条对照）
漂移检测
「技术必要性」合规标准（需满足以下任一条件）：
| 标准 | 描述 | 有效示例 | 无效示例 |
|---|---|---|---|
| 实现依赖 | 无此设计则 PRD 功能无法实现 | 「认证功能需要 Token 刷新机制」 | 「加个缓存更好」 |
| 安全合规 | 安全/合规强制要求 | 「PCI DSS 要求加密存储」 | 「建议加密」 |
| 稳定性保障 | 无此设计系统不稳定 | 「异步处理需要 DLQ 防止消息丢失」 | 「加 DLQ 更完善」 |
| 行业惯例 | 公认的工程最佳实践 | 「API 需要版本号以支持演进」 | 「加版本号更规范」 |
技术必要性标注格式要求：