用途：在写代码之前，对涉及代码变更的方案做设计质量评审，判断其是否结构良好（可维护、可测试、解耦合理），而不只是能否解决问题。它是 solution-review（面向任意方案的决策级评审）在代码领域的专用补充；涉及代码的方案建议两者同时使用。PDCA 宿主通过 frontmatter dependencies 声明本技能，缺失时宿主启动即中止。
主要能力：分三层评审。Layer A 架构级质量属性：可测试性（Clean Architecture）、模块化、可靠性与容错、可扩展性、依赖方向（稳定依赖原则与依赖规则），并含跨进程/层边界的运行时初始化位置、边界合法性与归属分类检查。Layer B 代码级指标（每次代码变更必做）：偶然复杂度（Brooks）、耦合类型（Myers 与 Connascence）、内聚梯度（Yourdon-Constantine）、变更放大（Fowler 霰弹式修改）、技术债象限、复杂度度量（McCabe 圈复杂度、SonarSource 认知复杂度）、迪米特法则。Layer C 安全：仅当触及信任边界时做 OWASP Top 10 轻量检查。
使用方式：先确认方案涉及代码；按范围选择 Layer A 全量或快速路径并在报告中说明；对每次代码变更逐项给出 Layer B 的通过/失败与理由；仅在触及认证、输入、数据存储或外部通信时执行 Layer C；输出结构化评审报告，含逐项结论、阻断/非阻断分类与总体判定，并对阻断项给出优化方向。
适用场景：评审含代码结构决策的设计文档、技术提案、新模块、API 设计、重构或依赖变更；回答“这段代码设计得好吗”“可维护吗”“耦合可接受吗”等问题。
限制：仅适用于代码方案，非代码方案（配置、流程、工具、无代码的架构决策）应改用 solution-review。阻断项包括依赖方向倒置、业务逻辑无法隔离测试、内容耦合或共享可变状态、无意识引入的鲁棒性技术债、霰弹式修改、设计层违反 OWASP 类别，以及存在明显更优且当前范围内可行的架构却未明确接受带偿还计划的技术债。具体阈值、框架出处与完整阻断/非阻断标准见 reference.md。