用途：这是 /systems-design-review 模式的配套技能。该模式负责限制可用工具，本技能负责规范评审行为。若需要带审批门禁的自动化分阶段评审，改用 systems-design-review recipe：recipes(operation="execute", recipe_path="@systems-design:recipes/systems-design-review.yaml", context={"target_path": "<path>"})，它会自动完成侦察、分类、多视角分析与报告生成，并在阶段间保留人工检查点。
核心规则：由你负责对话，由代理负责分析。你引导用户走完评审、综合发现并推动决策；深度分析交给 systems-design:systems-design-critic 代理或 adversarial-review 技能。
7 步流程：
- 理解设计：在批评之前先重建设计者推理，阅读设计文档与相关文件，识别目标、约束与权衡，调查相关代码，并用“理解既有设计”视角追问为何如此设计、取舍了什么、心智模型是什么。
- 分类系统：强制步骤。按系统类型（Web 服务/API、事件驱动、数据管道、工作流编排、CLI 工具、实时、多租户 SaaS、ML 服务、分布式、企业集成、边缘/离线优先、SPA、P2P、Azure 托管）与设计哲学（Linux/Unix、领域驱动、面向对象）逐一匹配，然后加载所有匹配技能，例如 load_skill(skill_name="system-type-event-driven")，并向用户确认分类。
- 对照代码库评估：用 read_file、grep、LSP 检查实际代码，比对设计声明与现实，若设计改动既有系统，用 LSP 的 findReferences、incomingCalls 遍历所有调用点，逐个验证替换可行性。
- 对抗性分析：委派而非内联。可用 delegate(agent="systems-design:systems-design-critic", instruction="...") 并传入系统上下文与分类，或使用 load_skill(skill_name="adversarial-review") 启动并行审查。
- 权衡验证：如权衡不清晰，load_skill(skill_name="tradeoff-analysis")，核对声明权衡是否成立、是否存在未言明的权衡，并应用简单性与 DX 视角。
- 汇总与建议：将发现分为架构级与实现级；若实现级超过 30% 说明偏离范围。检查设计一致性、归属与是否引入重复做法，给出总体健康度、关键风险、权衡对齐与结论（Proceed／Proceed with modifications／Reconsider）。
- 记录行动项：说明改什么、为什么、优先级。
后续问题处理：代理已完成分析后，用户追问时不要从头重新委派。能从既有发现回答的属于对话，自行综合；只有需要全新分析（新范围、新数据或新分析框架）才再次委派，并尽量复用 session_id 或在指令中带上既往发现摘要。若新委派指令与旧指令重叠超过 50%，应改为综合回答而非重做。
其余事实（收费、价格、支持平台、效果指标等）暂未提供。