architecture-review 是一个代码库架构审查技能，来源于 getsentry/warden 项目，定位为资深工程师（staff engineer）级别的代码库健康审查。其核心理念是「宏观重于微观」：关注会随时间累积的结构性问题，而非个人代码风格偏好，目标是找出能够提升整体可靠性与可维护性的改进点。
审查维度
该技能从五个维度展开审查：
-
模块复杂度：找出增长过大或承担过多职责的文件。规模检查方面，标记超过 500 行的文件，并将超过 800 行的文件作为疑似单体模块进行深入调查。职责计数方面，统计文件中不同关注点的数量（错误处理、校验、I/O、编排），若单个文件超过 3 个则表明需要拆分。扇出方面，从 10 个以上其他模块导入的文件可能承担了过多协调工作。对每个过大的模块，需要提出包含具体新文件名与职责的拆分方案。
-
静默失败模式：找出失败却没有任何提示的代码。包括被吞掉的错误（catch 块返回默认值但不记录日志或回调）、空返回（函数返回 [] 或 null，调用方无法区分「无结果」与「操作失败」）、缺少错误回调（异步操作没有 onError 或 onFailure 处理器）、静默兜底（如 value ?? defaultValue 这类掩盖上游问题的代码）。对每种情况，需要说明丢失了什么信息以及如何将其暴露出来。
-
类型安全缺口：找出绕过 TypeScript 安全性的地方。包括不安全类型断言（没有运行时校验的 as SomeType）、正则匹配断言（假设 .match() 后捕获组存在却不检查）、可选链滥用（?. 链虽然避免了 null 错误但掩盖了 null 的来源）、泛型索引访问（obj[key] 中 key 可以是任何值）。对每处缺口，建议类型安全的替代方案（类型谓词、显式检查等）。
-
测试覆盖分析：映射已测试内容与关键内容之间的差距。包括未测试的关键路径（核心业务逻辑、编排、错误处理）、边界情况缺口（空输入、null 值、边界条件）、集成缺口（只有单元测试的跨模块流程）、回归覆盖（修复了 bug 却没有对应测试）。按风险排序：热点路径中未测试的代码 > 未测试的边界情况 > 未测试的工具函数。
-
LLM 友好性：评估代码库对 AI 辅助开发的支持程度。包括 JSDoc 覆盖（导出的函数是否有清晰文档）、命名清晰度（函数与变量名能否在不读实现的情况下被理解）、错误信息（错误是否可操作，是否说明了出错原因与修复方式）、配置陷阱（容易被错误配置且后果不明显的设置）。
分析方法
该技能规定的分析步骤为：先映射架构，阅读主要入口点并理解模块结构，列出所有目录及其职责；然后找出巨型文件，按行数搜索最大的文件，逐个阅读并归类其职责；接着追踪错误路径，跟随操作失败时发生的情况，定位错误信息在哪里丢失；之后审计类型断言，搜索 as 断言与 .match( 模式，验证每处都有适当校验；再映射测试覆盖，列出所有 *.test.ts 文件并与源文件对比找出缺口；最后检查文档，抽样公共 API 的 JSDoc 是否存在及其质量。
报告前检查清单
在最终确定报告前，需确认：已阅读主要入口点并理解架构；已识别最大/最复杂的模块；已检查关键路径中的错误处理；已搜索类型断言并验证其安全性；已对照关键模块映射测试覆盖；建议是具体的（含文件名、行号、提议的拆分方案）。
输出格式与严重级别
输出结构为：执行摘要（3-5 条最具影响力的发现要点）、按优先级排列的问题（每个问题包含 Problem：哪里有问题及为何重要；Evidence：具体文件、行号、模式；Recommendation：包含文件名和结构的具体修复方案）、以及「运行良好的部分」（列出需要保留的架构优点，不要破坏本来没问题的东西）。严重级别分为四级：critical（导致当前可靠性问题的架构缺陷）、high（会随代码库增长而累积的问题）、medium（值得修复但不紧急）、low（锦上添花的改进）。
明确不报告的内容
该技能明确要求不报告：代码风格偏好、轻微命名问题、单行修复、以及已在处理中的问题。
适用场景与限制
该技能适用于对代码库进行结构性健康审查、识别技术债与架构风险、评估 AI 辅助开发的友好度等场景。其审查对象为代码库本身，需要能够访问源码、测试文件与配置。关于该技能的具体安装方式、运行命令、支持的平台、收费情况等，资料中暂未提供。