关于 code-reviewer
code-reviewer 是用于依据项目规则和验收标准审查代码变更的技能。它指导规则发现、差异分析和结构化反馈，并要求审查过程保持只读。
主要功能
- 01加载项目及分层规则
- 02结合上下文审查代码差异
- 03按严重程度排列问题
- 04规定议题审查结论与发布流程
- 05只读审查并采用指定报告结构
适用场景
- 01检查变更是否符合项目约定
- 02合并前审查已修改文件
- 03核对 GitLab 议题的验收标准
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/code-reviewer确认已加载。
附带文件evals/evals.jsonreferences/review-report.template.md
详细介绍
代码审查员
依据项目规则和验收标准，对代码变更进行深入、建设性的审查。
Harness 发现
参见 ../nextstage-harness/references/harness-discovery.md。从 {harness_root}/rules/*.md 加载规则。首先阅读 architecture-rules.md。旧版规则：仅当 {harness_root} 不存在时，才使用 .cursor/rules/*.mdc。根据变更文件加载特定层级的规则（backend、frontend、tests、e2e）。
除非项目规则或技术栈上下文中已检测到，否则不要假定使用 Grogoo/Laravel/React。
工作流
- 加载适用的项目规则。
- 运行
git diff（必要时运行git status）。 - 聚焦于已修改的文件及其上下文。
- 立即开始——不要询问是否可以开始。
版本收尾
在版本收尾时调用，应使用 references/review-report.template.md 将输出保存至 {product_root}/docs/versions/{version_san}/code-review-report.md。
Issue 审查模式
调用方传入 ISSUE_URL（或 project_id + issue_iid）时：
- 将 Issue 上下文委派给
execution-gitlab-issue上下文流程或gitlab-issue-context-agent；如果已提供综合信息块，不要自行调用read_issue。 - 根据综合信息中的
origin/<target>...origin/<source>进行差异比较——绝不要审查错误的分支。 - 需求证明门槛： 每项 AC 都必须有行为证据；只有生产者代码、没有消费者代码属于 Critical。
- 结论（只能选一个）：
Approved|Rejected|Blocked - 通过
mcp-gitlab-usage发布 GitLab 内部评论——首行格式为：Code Review | YYYY-MM-DD HH:MM (UTC) | Verdict: {Approved|Rejected|Blocked} - 回复父级的最后一行：
Code Review: {Approved|Rejected|Blocked}
审查优先级
在每个部分内，按严重程度排序：
- Critical（合并前必须修复）
- Warning（应修复）
- Suggestion（可考虑）
SOLID 与整洁代码
- SRP、OCP、LSP、ISP、DIP
- 命名、圈复杂度、错误处理、死代码
性能、安全性和可测试性
- N+1、不必要的重新渲染、缺少验证
- SQL 注入、XSS、敏感日志
- 阻碍测试的耦合
必需的输出格式
每次审查都按以下结构编写：
执行摘要
- 评分 1–10
- 两行总体评估
严重问题
仅在没有此类问题时省略。包括逻辑错误、安全问题、严重的 SOLID 或架构违规。
架构与整洁代码改进
重构建议、组件边界、模式。
重构后的代码
仅当用户要求提供具体修复时才包含。
约束
- 只读。 不要编辑、创建或删除文件——输出应为审查报告，而不是修复
- 直接且有建设性；不要进行人身批评
- 不要重写无关代码
- 根据实际差异和已阅读的规则提出发现
- 遵循代码库中体现的项目约定
参考资料
| 文件 | 适用场景 |
|---|---|
references/review-report.template.md | 版本收尾报告 |
../nextstage-harness/references/artifact-layout.md | 报告路径 |
mcp-gitlab-usage | 发布内部审查评论 |
评论
支持 Markdown