技能（Skill）：审查代码库
目的 (Purpose)
从高级全栈和生产代码审查的角度来看，审查给定范围（单个文件、目录或整个存储库）的当前状态：架构、设计、技术债务、模式和整体质量。不依赖于 git diff。补充 review-code：review-code 重点关注当前更改（影响、回归、兼容性、副作用）；该技能侧重于给定范围的当前状态。
核心目标（Core Objective）
首要目标：生成结构化代码质量报告，涵盖给定范围（文件、目录或存储库）的架构、设计、技术债务、模式和整体质量。
成功标准（必须满足所有要求）：
- ✅ 范围确认：在分析开始之前确认用户的审阅路径或目录
- ✅ 涵盖所有维度：架构/边界、设计模式、技术债务/可维护性、跨模块依赖、安全/性能（当前状态）和具体建议都得到解决
- ✅ 引用的发现：每个发现都包含特定的文件：行引用并且是可操作的
- ✅ 符合调查结果格式：所有调查结果包括位置、类别（“范围”）、严重性、标题、描述和可选建议
- ✅ 处理大范围：对于大范围（整个存储库），输出按层/模块组织或与用户商定优先级子集
验收测试：报告是否涵盖了所有六个审查维度以及特定文件：给定范围的行引用和可操作的建议，而不依赖于 git diff？
范围边界（范围边界）
本技能负责：
- 查看给定路径、目录或完整存储库的当前状态
- 架构、设计模式、技术债务、跨模块依赖性和整体质量
- 审查范围内当前状态的安全和性能问题
本技能不负责：
- 仅差异或变更集审查（对这些使用“review-diff”）
- 结合范围+语言+cognitive技能的完整精心策划的评论（使用“评论代码”）
- 特定于语言/框架的约定分析（使用
review-dotnet、review-java、review-go等） - 仅针对安全性的审查（使用“review-security”）
- 仅关注绩效审查（使用“审查绩效”）
转交点：审查完成后，将结果交给“审查代码”进行聚合，或交给用户决定下一步（重构、规划、文档化）。
使用场景（用例）
- 新模块/服务：给定目录或文件的架构和实现审查。
- 遗留审计：路径或存储库的质量和风险审查。
- 配对/采样：查看同事指定的文件或目录，无需当前差异。
- 教学和标准：根据相同的审查维度解释或检查任意代码。
何时使用：当用户想要查看给定的路径、目录或存储库时，而不是“仅当前差异”。要仅审查本地更改，请使用 review-diff。要进行完整的精心策划的审核，请使用 review-code。
范围：此技能侧重于给定范围的当前状态（架构、设计、技术债务），不依赖于 diff。它补充了“审查代码”（精心安排）。 Skills.sh 选项（例如“code-review-excellence”）更为通用；这项技能强调界限、模式和整体素质。
行为（行为）
范围
- 输入定义范围：单个文件、目录或“repo root”等，由用户指定；允许多条路径。
- 不受差异限制：在给定范围内分析当前文件内容；不需要 git 更改集。如果用户还提供差异，它可以告知上下文，但不是唯一的输入。
对于范围内的每个文件（以状态/设计为中心）
- 架构和边界：模块/服务边界是否清晰、职责是否单一、依赖方向是否合理？
- 设计模式和一致性：模式使用得当吗？风格和模式与存储库/模块的其余部分一致吗？
- 技术债务和可维护性：重复、复杂性、可测试性、文档和评论与当前状态。
- 跨模块依赖和耦合：依赖过多、循环、接口稳定清晰？
- 安全和性能（当前）：当前实现中的输入验证、敏感数据、权限、资源使用和并发风险。
- 具体建议：可操作的重构或改进（使用 file:line）。
这项技能着眼于完整的实现和整体的位置，而不是“这个差异”。
语气和参考
- 以专业和工程为中心：审查是否会在生产中运行。
- 精确：参考特定位置（文件：行）。
范围和优先级
- 如果范围很大（例如整个存储库），则按层（模块/目录）输出或与用户就优先级子集达成一致，以避免肤浅、通用的结论。
输入与输出 (Input & Output)
输入（输入）
- 路径：一个或多个文件或目录路径（相对于工作空间根目录或用户给定的根目录）。
- 可选：语言/框架限制、重点（例如仅安全性、仅性能）。
默认值（确认或选择；避免自由文本）：
| 项目 | 默认 | 何时偏离 |
|---|---|---|
| 路径 | 回购根目录 | Offer: [Repo root] [当前文件目录] [列出要选择的顶级目录];用户选择。 |
| 范围大 | 按层（按模块/目录输出） | 用户可以选择优先级子集（例如从顶级目录中选择）。 |
运行前确认： (1) *查看存储库根目录？* [默认] 或用户从选项中选择路径。 (2) 如果范围很大，则使用默认的“按层”或用户从提供的列表中选择优先级子集。
输出（输出）
- 每个文件或模块：针对上述维度的结论和建议。
- 格式：标题（文件或模块）、列表和引用（文件：行），以便读者可以跟踪源代码。
限制（限制）
硬边界（Hard Boundaries）
- 当范围不明确“差异”时，不要假设“仅审查差异”；该技能默认为给定范围内的完整代码。
- 不要在没有具体地点或可行建议的情况下给出结论。
- 不要使用含糊的语言（例如，“可能是错误的”，没有类型和修正方向）。
技能边界 (Skill Boundaries)
不要做这些（其他技能可以处理它们）：
- 不要仅审查 git diff 或当前更改集 — 使用
review-diff进行仅 diff 范围 - 不要跨范围+语言+cognitive维度协调多种审核技能——使用“审核代码”进行全面协调的审核
- 不要执行特定于语言的约定分析（.NET、Java、Go 等）——使用相应的语言审查技能
何时停止并交接：
- 当调查结果完成后，如果属于精心策划的审核流程的一部分，则将其移交给“审核代码”
- 当用户只需要 diff 分析时，重定向到
review-diff - 当用户仅需要深入了解安全性或性能时，重定向到“审查安全性”或“审查性能”
自检（Self-Check）
核心成功标准
- 范围已确认：在分析开始之前确认用户的审阅路径或目录
- 涵盖所有维度：架构/边界、设计模式、技术债务/可维护性、跨模块依赖、安全/性能（当前状态）和具体建议都得到解决
- 引用的调查结果：每个调查结果都包含特定的文件：行引用并且是可操作的
- 符合调查结果格式：所有调查结果包括位置、类别（“范围”）、严重性、标题、描述和可选建议
- 处理大范围：对于大范围（整个存储库），输出按层/模块组织或与用户商定优先级子集
流程质量检查
- 审核范围是否与用户的路径/目录匹配？
- 是否涵盖边界、模式、技术债务、依赖性和耦合以及当前的安全/性能？
- file:line 是否引用了问题？
- 是否针对重要问题给出了具体的重构或改进建议？
验收测试
该报告是否涵盖了所有六个审查维度以及特定文件：行引用和给定范围的可行建议，而不依赖于 git diff？
示例（示例）
示例 1：单个目录
- 输入：路径
src/auth/；查看其下的所有相关代码。 - 预期：每个文件、列表架构和边界、设计模式和一致性、技术债务和可维护性、跨模块依赖性和耦合、当前安全性和性能；参考行号并给出改进建议；不依赖于当前的 git 更改。
示例 2：单个文件
- 输入：路径
pkg/validator/validator.go。 - 预期：对文件进行全面审查：其角色和边界、入口点和依赖项、模式和一致性、技术债务和可测试性、当前安全性和性能；参考行号。
边缘情况：整个仓库
- 输入：路径是存储库根或“整个项目”。
- 预期：按层（模块/目录）输出或给出高级摘要和风险列表（架构、依赖项、技术债务），然后与用户就子集达成一致以进行更深入的审查；避免长而浅的传球。
附录：输出合约
当此技能产生评论时，它遵循此契约，以便可以将结果与其他原子技能聚合（例如通过 review-code）：
| 元素 | 要求 | |||
|---|---|---|---|---|
| 范围 | 用户指定的路径；范围内的完整代码；不受差异约束。 | |||
| 调查结果格式 | 每个发现必须包括位置（path/to/file.ext 或 file:line）、类别（此技能的范围）、严重性（严重\ | 主要\ | 次要\ | 建议）、标题、描述和可选的建议。 |
| 每个文件/模块 | 标题、列表、参考文献（文件：行）。 | |||
| 维度 | 架构和边界； 设计模式和一致性；技术债务和可维护性；跨模块依赖和耦合；安全性和性能；具体建议。 | |||
| 范围大 | 按层输出或商定优先级子集；避免浅通过。 |
与聚合兼容的示例查找：
- **Location**: `pkg/auth/service.go:31`
- **Category**: scope
- **Severity**: major
- **Title**: Module boundary unclear; auth logic mixed with HTTP handling
- **Description**: Controller contains validation and token logic; hard to test and reuse.
- **Suggestion**: Extract auth logic into a dedicated service; keep controller thin.