القائمة
当 `/challenge` 需要设计侧规范契约闭合证据（架构与系统设计文档三维审查）时加载；产出可锚点、按严重度分级的发现供纳入 07_CHALLENGE_REPORT，不作脱离 challenge 上下文的终局裁决。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/Haaaiawd/ANWS --skill design-reviewerيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
当用户在 skills-only 环境中需要判断应该从哪个 anws 工作流开始，或需要在 forge / change / genesis / probe / blueprint / challenge / upgrade 之间路由时使用。它是 anws 工作流集合的导航入口。
纯静态「契约忠实度 / 实现侧证据」审查：对照 PRD、ADR、系统设计、05A_TASKS 与 05B_VERIFICATION_PLAN，围绕契约闭合、任务兑现、架构健康、安全边界、验证证据与回流一致性产出可追溯结论；供 /challenge（CODE/FULL）与 /forge（Step 3 §3.6 波末）共用。
当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程与暗物质（missing_components）。由 **`/genesis` Step 1** 在 Step 0 已确定 `TARGET_DIR = .anws/v{N}` 后调用；与 **同工作区 `/genesis`** 连用。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | design-reviewer |
| description | 当 `/challenge` 需要设计侧规范契约闭合证据（架构与系统设计文档三维审查）时加载；产出可锚点、按严重度分级的发现供纳入 07_CHALLENGE_REPORT，不作脱离 challenge 上下文的终局裁决。 |
设计缺陷在实现前被命名，比在上线后被追债便宜一个数量级。
在 /challenge 链中，你是设计侧证据层：证明哪些契约在系统边界、接口、状态、时序与错误路径上仍未闭合；不代替 CHALLENGER 做整份报告的终局判定或路由，只交付可合并、可验收的设计发现块。
[!IMPORTANT]
设计审查的目标不是展示聪明，而是让「文档承诺—推演—缺口」可被第三方逐条对照。
- 唤醒，不是宣告：先恢复设计意图与 ADR 取舍，再标缺口；跳过意图还原的条目容易变成泛泛「风险」。
- 展开，不是单线：同一结论须在 PRD、架构总览、System Design、ADR 的交叉阅读下仍成立；单文件扫读会漏默认态与隐式耦合。
- 升维，再落地：把问题抬到契约层（边界/接口/状态机/故障语义），再回到可引用锚点；停在比喻或停在目录名都不可交付。
- 重建，而非复述：用证据链重建「若不补，何处必错」，而不是改写或重复原文句子。
[!IMPORTANT] 共用持久化报告契约（精确、有据、不重复、禁泛泛、单写者、子代理闭环）以
.agents/skills/output-contract/SKILL.md为准；本 skill 只补充设计审查发现的锚点与严重度要求。
- 可追溯：「发现 → 引文或概括 → 推理链 → 影响 → 建议」同序可查；无推理链则不得标 Critical/High。
- 锚点：每条发现附最小足够锚点（
path、明确标题/小节名、或稳定章节 id）；禁止仅写「见架构文档」。- 表内专条：核心发现清单内 发现 / 影响 / 建议 各一句（极短复合句允许）。
- 质量优于数量：少数高信号发现优先于大量猜测。
[!IMPORTANT]
维度 1（系统设计）：批判前用
sequential-thinking3–5 个 thought 固定设计意图与核心假设，再对照 SD-1..6。
维度 2（运行模拟）与维度 3（工程实现）：必须各走一轮sequential-thinking（各 3–5 个 thought），用于序列推演与可构建性/可验证性判断；自然 CoT 不可替代此两维的 CLI 义务（无 CLI 时须在输出中显式声明阻塞并降级为「待父代理补证」，不得伪造 thought 列表）。
任意 thought 应可回答：前提是什么、哪一步会断、断在哪个文档锚点。
02_ARCHITECTURE_OVERVIEW.md、全部 04_SYSTEM_DESIGN/*.md、全部 03_ADR/*.md；若 challenge 上下文已挂载 01_PRD.md，一并用于交叉一致性。07_CHALLENGE_REPORT.md 的「设计审查发现」节。硬边界：证据为本（无具体引用+推理链则不得写入发现清单）；尊重已文档化的 ADR 权衡（无新证据不翻旧账）；不涉及实现代码级细节（审查对象为设计契约与可构建性语义）。
建立可读的设计模型：列出组件/边界、对外接口清单、核心状态与故障语义、与 ADR 的依赖关系；标记空白区（未写协议、未写超时/降级、未写错误码语义等）。
无模型的扫表只会产出标签云；challenge 需要的是可合并进契约模型的闭合性证据。
按下列三表逐项过检；维度 2、3 在过检前完成各自强制的 sequential-thinking 轮次；将结果仅记录为候选发现，进入下一节再包装为 DR-ID 行。
三维框架保证「结构—时间—建造」三类盲区不被单一路径审查漏掉。
目标: 验证架构的完整性、一致性和边界清晰度。
| # | 检查项 | 关注要点 |
|---|---|---|
| SD-1 | 架构一致性 | 同一组件在 PRD、Architecture、System Design 中的描述是否矛盾？ |
| SD-2 | 边界清晰度 | 每个系统的职责范围是否明确？是否存在职责重叠？ |
| SD-3 | 依赖合理性 | 系统依赖是否无环？是否存在隐藏耦合？ |
| SD-4 | 接口完整性 | 所有跨系统接口是否完整定义（输入/输出/错误/协议）？ |
| SD-5 | 状态管理 | 系统状态转换是否清晰定义？边缘状态是否处理？ |
| SD-6 | 数据模型完整性 | 实体关系是否跨文档一致？是否存在孤儿实体？ |
目标: 在脑中「运行」系统，发现时序、状态和并发问题。
| # | 检查项 | 关注要点 |
|---|---|---|
| RS-1 | 时序一致性 | 时序模型是否合理？是否存在"必须先于"的矛盾？ |
| RS-2 | 状态同步 | 分布式状态下，副本是否可能发散？最终一致性在这里是否可接受？ |
| RS-3 | 并发处理 | 两个操作冲突时会怎样？是否有解决策略？ |
| RS-4 | 边界条件 | 空状态、满状态、溢出——各自如何处理？ |
| RS-5 | 故障传播 | 组件 A 故障时如何影响 B、C？是否存在级联风险？ |
| RS-6 | Happy Path 偏见 | 只设计了正常路径？错误/超时/部分失败路径呢？ |
目标: 验证设计可构建、可测试、可维护。
| # | 检查项 | 关注要点 |
|---|---|---|
| EI-1 | 可测试性 | 核心逻辑能否被单元测试？是否有 Mock 的接缝？ |
| EI-2 | 可维护性 | 如果需求变更，需要改多少文件？ |
| EI-3 | 性能瓶颈 | 设计中是否隐藏了 N+1 查询、无界循环或 O(n²)？ |
| EI-4 | 安全面 | 认证边界是否清晰？敏感数据静态/传输加密？输入校验？ |
| EI-5 | 可观测性 | 凭设计中的日志/指标方案能否调试生产问题？ |
| EI-6 | 技术栈契合度 | 选定的技术是否真正支持所需功能？版本兼容性？ |
| 等级 | 判定标准 | 所需行动 |
|---|---|---|
| Critical | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
| High | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
| Medium | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
| Low | 润色项或轻微不一致。 | P3 — 后续跟踪 |
将候选发现过滤为可交付集：按严重度排序；为每条分配 DR-xx；填写摘要表与（仅 Critical/High）详情；发现/影响/建议各一句；文档位置列使用最小可用锚点。
challenge 报告需要可合并、可审计的块状证据；冗长复述会淹没 P0/P1。
sequential-thinking 义务一致。07_CHALLENGE_REPORT.md 对应章节而不改表头语义。按以下结构生成发现，适合纳入 07_CHALLENGE_REPORT.md：
## 设计审查发现
### 摘要
| 维度 | 发现数 | Critical | High | Medium | Low |
|------|:------:|:--------:|:----:|:------:|:---:|
| 系统设计 | — | — | — | — | — |
| 运行模拟 | — | — | — | — | — |
| 工程实现 | — | — | — | — | — |
| **合计** | **—** | **—** | **—** | **—** | **—** |
**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
---
### 核心发现清单
| ID | 维度 | 严重度 | 文档位置 | 发现 | 影响 | 建议 |
|----|------|--------|----------|------|------|------|
| DR-01 | 系统设计 | Critical | 02_ARCHITECTURE_OVERVIEW.md §X | 边界定义冲突，两个系统职责重叠 | 实现阶段职责漂移、返工风险高 | 重新划清系统边界并更新引用 |
| DR-02 | 运行模拟 | High | 04_SYSTEM_DESIGN/... §Y | 故障传播路径未定义 | 级联失败时无法收敛 | 增加超时/降级/重试策略 |
| DR-03 | 工程实现 | Medium | ADR-00X / System Design §Z | 可测试接缝不足 | 后续验证成本高 | 增加接口隔离或 mock 接缝 |
> 仅输出真正影响设计判断的问题。低价值措辞、重复担忧不要进入清单。
---
### Top Findings 详情（仅展开 Critical / High）
#### DR-01 [标题]
**严重度**: Critical
**文档位置**: [精确的文件和章节引用]
**证据**:
- 文档分析: [来自 PRD/Architecture/ADR 的具体内容]
- 推理链: [基于 `sequential-thinking` 的分析]
- 类比: [其他系统中的类似已知失败，如适用]
**影响**:
- [不修复会发生什么]
**建议**:
- [最小修复方向]
对照清单完成自检：引用、推理、严重度、ADR 尊重、可操作性；剔除重复与空话；确认与 challenge 父子合并约定一致（单一写盘归父代理时，本 skill 只交付块）。
未过闸的设计块会污染契约模型，导致误报 P0 或漏报真实闭合缺口。
sequential-thinking 强制要求。可选：若环境支持并行与上下文切分，父代理可将**每一维（SD / RS / EI）或「文档只读合并摘要」**委派子代理；子代理仅返回结构化发现草案与锚点，不得自行写 07_CHALLENGE_REPORT.md。
父代理：合并入 challenge 报告形状、去重、统一 DR 编号、执行 Step 4.5 与路由语言；单一写盘。
交接清单（子代理 → 父代理）：
sequential-thinking 已执行声明或阻塞说明。<completion_criteria>
02_ARCHITECTURE_OVERVIEW.md、04_SYSTEM_DESIGN/*、03_ADR/*（及 challenge 上下文中的 PRD 若可得）。sequential-thinking 强制轮次。/challenge 终局裁决与写盘责任（除非会话明确指派你为父代理且已承担写盘）。
</completion_criteria>