by 运行时依赖
安装命令
点击复制技能文档
架构审查技能核心原则 这是一个架构审查，而不是代码审查。在MODULE/COMPONENT级别进行评估——系统结构、边界、数据流、设计权衡。忽略代码风格、变量命名、函数级实现、个别错误、格式。
好的例子： "web 模块直接依赖 sync 引擎，违反分层架构" 不好的例子： "第 42 行的变量命名不规范" 好的例子： "缺少统一的错误传播策略" 不好的例子： "这个 try/except 应该 catch 更具体的异常"
这个技能生成报告，不修改、不实现任何东西。输出：结构化的架构评估报告。不编辑文件，不改变代码，不提交 PR。仅报告。
第 0 阶段：读取配置 在进行任何分析之前，读取和理解当前的维度和报告模板。这些文件与此 SKILL.md 文件一起存放——用户可能已经自定义了它们。读取 dimensions.md 文件（相对于此 SKILL.md 文件）。解析每个 ## Dimension: 部分。构建一个包含 id、描述、评分标准和检查清单的活动维度列表。计算 N = 找到的维度数量。读取 report-template.md 文件（相对于此 SKILL.md 文件）。了解整体报告结构和每个维度的输出格式。这个模板决定了最终报告的组装方式。读取 examples.md 文件（相对于此 SKILL.md 文件）以参考输出样式。如果任何文件丢失，警告用户并回退到内联默认值。
第 1 阶段：发现 OpenSpec 文档 定位项目的 OpenSpec 规范：在项目根目录中搜索 openspec/specs/ 目录。如果找不到，搜索 specs/、spec/ 或任何 *.spec.md 文件。如果找不到规范，要求用户提供规范路径或切换到 --spec-only 模式并提供文档。对于每个找到的规范文件：解析 ### Requirement: 块及其 #### Scenario: 子块。提取要求名称、SHALL/MUST 语句和 GIVEN/WHEN/THEN 场景。构建一个结构化的要求列表。
第 2 阶段：扫描项目架构 步骤 2.0：检查以前的审查报告 查找 {project_root}/.arch-review/ 目录。如果存在，读取最新的报告文件（按日期排序）。从以前的报告中提取：架构概述部分（图表、模块注册表、数据流）——作为基线以前识别的问题（已选中 + 推迟）——检查是否重复出现任何结构性变化自上次审查如果存在以前的报告，这次审查成为增量审查：重用架构概述作为起点，仅更新更改的部分标记重复出现的问题（在上次报告中出现并仍然存在）注意已解决的问题（在上次报告中但不再适用）如果没有以前的报告，进行完整扫描。
步骤 2.1：扫描架构（如果没有以前的报告，或为了验证/更新） 如果代码存在（跳过 spec-only 模式）：关注结构，而不是实现细节：从包文件中检测项目语言和框架。映射顶级模块/包布局及其职责。识别架构边界：主要组件是什么，它们如何连接？注意依赖方向（谁依赖于谁在模块级）。识别数据存储、外部集成和通信模式。不要读取个别函数体。仅扫描模块级结构、入口点和接口。
第 3 阶段：构建共享上下文 构造每个子代理将接收的共享上下文有效载荷： SHARED_CONTEXT：
- 项目摘要：语言、框架、域
- OpenSpec 要求列表（名称 + SHALL 语句，无完整场景，除非很小）
- 来自第 2 阶段的代码结构摘要
- 用于更深入检查的关键文件路径
第 4 阶段：维度审查 主代理直接执行审查——一次一个维度。不要委托给子代理通过 Task 工具。你（主代理）做所有工作。 执行模式 默认：顺序（主代理） 一次评估每个维度，一个接一个。对于每个维度，读取相关项目文件，应用评分标准，产生评估。这确保使用正确的模型（用户为此对话选择的模型）。 可选：并行（子代理） 仅在用户明确说 "并发" / "parallel" / "用子代理" 时使用 Task 工具。当使用子代理时，传递模型参数，使用 ALIAS_MAP 下面的完整 slug。 ALIAS_MAP（仅用于子代理模式）： 别名 全部 slug opus claude-4.6-opus-medium-thinking sonnet claude-4.6-sonnet-medium-thinking gemini gemini-3.1-pro codex gpt-5.3-codex fast composer-2-fast 每个维度的评估过程 对于活动列表中的每个维度： 读取 dimensions.md 中的维度评分标准和检查清单。 读取此维度的相关项目文件： 模块化 → 模块布局、导入结构、包边界 数据流 → 状态存储、数据管道、异步模式 可扩展性 → 资源使用、增长模式、瓶颈点 弹性 → 错误处理