转交点 ：审查完成后，将结果交给“审查代码”进行聚合，或交给用户决定下一步（重构、规划、文档化）。

使用场景（用例）

• 新模块/服务 ：给定目录或文件的架构和实现审查。
• 遗留审计 ：路径或存储库的质量和风险审查。
• 配对/采样 ：查看同事指定的文件或目录，无需当前差异。
• 教学和标准 ：根据相同的审查维度解释或检查任意代码。

何时使用 ：当用户想要查看给定的路径、目录或存储库 时，而不是“仅当前差异”。要仅审查本地更改，请使用 review-diff。要进行完整的精心策划的审核，请使用 review-code。

范围 ：此技能侧重于给定范围的当前状态 （架构、设计、技术债务），不依赖于 diff。它补充了“审查代码”（精心安排）。 Skills.sh 选项（例如“code-review-excellence”）更为通用；这项技能强调界限、模式和整体素质。

行为（行为）

范围

• 输入定义范围 ：单个文件、目录或“repo root”等，由用户指定；允许多条路径。
• 不受差异限制 ：在给定范围内分析当前文件内容 ；不需要 git 更改集。如果用户还提供差异，它可以告知上下文，但不是唯一的输入。

对于范围内的每个文件（以状态/设计为中心）

1. 架构和边界 ：模块/服务边界是否清晰、职责是否单一、依赖方向是否合理？
2. 设计模式和一致性 ：模式使用得当吗？风格和模式与存储库/模块的其余部分一致吗？
3. 技术债务和可维护性 ：重复、复杂性、可测试性、文档和评论与当前状态。
4. 跨模块依赖和耦合 ：依赖过多、循环、接口稳定清晰？
5. 安全和性能（当前） ：当前实现中的输入验证、敏感数据、权限、资源使用和并发风险。
6. 具体建议 ：可操作的重构或改进（使用 file:line）。

这项技能着眼于完整的实现和整体的位置 ，而不是“这个差异”。

语气和参考

• 以专业和工程为中心 ：审查是否会在生产中运行。
• 精确 ：参考特定位置（文件：行）。

范围和优先级

• 如果范围很大（例如整个存储库），则按层（模块/目录）输出或与用户就优先级子集达成一致，以避免肤浅、通用的结论。

输入与输出 (Input & Output)

输入（输入）

• 路径 ：一个或多个文件或目录路径（相对于工作空间根目录或用户给定的根目录）。
• 可选 ：语言/框架限制、重点（例如仅安全性、仅性能）。

默认值（确认或选择；避免自由文本）：

运行前确认 ： (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）：

与聚合兼容的示例查找：

- **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.

Weekly Installs

50

Repository

nesnilnehc/ai-cortex

GitHub Stars

6

First Seen

Feb 6, 2026

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

codex50

opencode49

github-copilot48

gemini-cli48

amp47

kimi-cli47