name: review-codebase
description: 以高级全栈架构师与生产代码评审视角，对指定文件、目录或仓库范围内的代码现状进行评审，关注架构、设计、技术债、模式与整体质量，不依赖 git diff。
tags: [eng-standards]
version: 1.0.0
related_skills: [review-code]
recommended_scope: project

Skill: 评审代码库 (Review Codebase)

目的 (Purpose)

以高级全栈软件架构师与生产代码评审者的视角，对指定范围内的代码现状（单文件、目录或整个仓库）进行评审，关注架构、设计、技术债、模式与整体质量，不依赖 git diff；与 review-code 互补 — review-code 关注本次变更（影响、回归、兼容性、副作用），本技能关注指定范围的代码现状。

适用场景 (Use Cases)

• 新模块/新服务：对指定目录或文件做整体架构与实现评审。
• 遗留代码审计：对某路径或仓库做全面质量与风险评审。
• 结对/抽查：对同事指定的文件或目录做评审，无需基于本次变更。
• 教学与规范：按同一套评审维度讲解或检查任意代码片段。

何时使用：当用户希望评审指定路径、目录或仓库的代码，而非「仅当前 diff」时；若仅需评审本地变更，应使用 review-code 或 /review-code。

行为要求 (Behavior)

评审范围

• 输入决定范围：由用户或调用方指定 — 单文件路径、目录路径、或「当前仓库根」等；可接受多个路径。
• 不限于 diff：分析指定范围内的当前文件内容，不依赖 git 变更集；若用户同时提供 diff，可结合上下文但不以 diff 为唯一输入。

对每个纳入文件须覆盖（以「现状/设计」为核心）

1. 架构与边界：模块/服务边界是否清晰、职责是否单一、依赖方向是否合理。
2. 设计模式与一致性：是否恰当使用模式、与同仓库/同模块其他代码风格与模式是否一致。
3. 技术债与可维护性：重复、复杂度、可测试性、文档与注释是否与现状匹配。
4. 跨模块依赖与耦合：依赖是否过多、循环依赖、接口是否稳定清晰。
5. 安全与性能（现状）：输入校验、敏感数据、权限、资源使用与并发等当前实现中的风险。
6. 具体建议：对上述问题给出可落地的重构或改进建议（含 file:行）。

本技能看的是当前文件的完整实现与在整体中的位置，而非「本次 diff」。

语气与引用

• 专业、工程化：按「将上线 SaaS 生产环境」的严格程度评审。
• 严格且精确：指出问题时常引用具体位置（文件:行）。

范围与优先级

• 若指定范围过大（如整仓），可先按模块/目录分层输出，或与用户约定优先评审的子集，避免泛泛而谈。

输入与输出 (Input & Output)

输入 (Input)

• 路径：一个或多个文件或目录路径（相对于工作区根或用户给定根）；未指定时默认可为当前仓库根或用户声明的「当前关注路径」。
• 可选：语言/框架约束、评审重点（如仅安全、仅性能）等，由用户或调用方提供。

输出 (Output)

• 按文件或模块：对纳入范围内的文件给出上述维度的评审结论与建议。
• 格式：使用标题（文件名或模块）、列表与引用（file:行），便于读者对照源码。

禁止行为 (Restrictions)

• 禁止在未明确指定范围时擅自假定「只评 diff」；本技能默认面向指定范围内的完整代码。
• 禁止只给结论不给具体位置或可落地建议。
• 禁止使用非专业或模糊表述（如「可能有问题」却不指明类型与修复方向）。

质量检查 (Self-Check)

• [ ] 评审范围是否与用户指定的路径/目录一致？
• [ ] 是否围绕「现状/架构/设计」做评审，覆盖边界、模式、技术债、依赖与耦合、安全与性能现状等？
• [ ] 指出问题时是否带有 file:行 等可定位引用？
• [ ] 是否对重要问题给出了可落地的重构或改进建议？

示例 (Examples)

示例一：单目录评审

• 输入：路径 src/auth/，评审该目录下所有相关代码。
• 预期行为：按文件列出架构与边界、设计模式与一致性、技术债与可维护性、跨模块依赖与耦合、安全与性能现状等，引用具体行号，并给出改进建议；不依赖本次 git 变更。

示例二：单文件评审

• 输入：路径 pkg/validator/validator.go。
• 预期行为：对该文件做完整评审，包含在整体中的位置与边界、入口与依赖关系、模式与一致性、技术债与可测试性、安全与性能现状等，并引用行号。

边界示例：整仓评审

• 输入：路径为仓库根，或「整个项目」。
• 预期行为：可按模块/目录分层输出，或先输出高层结论与风险清单（架构、依赖、技术债等），再与用户约定优先深度评审的子集；避免一次性输出过长且泛泛的结论。