mcpField
N
neo-code-review

neo-code-review

github.com/benknightdark测试与质量735 次安装3 天前更新
代码仓库

关于 neo-code-review

neo-code-review 是执行只读代码审查的技能,面向代码、PR、提交和安全或性能审查。它按证据报告可操作的问题,并扫描跨文件重复逻辑和硬编码配置。

主要功能

  1. 01按指定范围检查代码与变更
  2. 02加载审查清单并分析相关上下文
  3. 03扫描跨文件重复实现与规则
  4. 04按严重程度输出有证据的问题

适用场景

  1. 01审查工作区、暂存变更或提交范围
  2. 02检查变更中的安全、性能和正确性风险
  3. 03查找重复业务逻辑或硬编码配置

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/benknightdark/neo-skills --skill neo-code-review

安装后在 Claude Code 中输入/neo-code-review确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
eval_queries.json
evals.json
references/
review-checklist.md
scripts/
git-diff-reviewer.py

详细介绍

代码审查

遵循此只读工作流。仅报告有证据支持且可采取行动的问题。

触发条件

  • 用户请求审查代码、PR、差异、提交、安全性、性能、测试或可维护性。
  • 用户询问多个文件之间是否有重复代码或逻辑,或者是否应集中管理硬编码值。
  • AI Agent 在交接前完成了代码、测试、配置或脚本的修改。

工作流

  1. 定义审查范围

    • 以用户提供的文件或代码片段作为主要审查范围。
    • 如果用户未提供范围,且当前目录是 Git 仓库,则运行:
      uv run skills/neo-code-review/scripts/git-diff-reviewer.py --working-tree
      
    • 对仅暂存的更改使用 --staged,对提交范围使用 --commit <range>。
    • 阅读相关代码、测试和现有约定。如果没有可审查的输入,请说明并停止。
    • 审查工作树时,将辅助脚本生成的已跟踪差异和每个未被忽略的未跟踪文件作为单独的输入。
  2. 加载审查规则

    • 在评估代码前阅读 review-checklist.md。
    • 根据更改识别实际使用的语言、框架和受影响的行为。不要仅凭文件名推断未经验证的规则。
  3. 执行跨文件一致性扫描

    • 根据审查目标以及相关的仓库源文件和配置文件构建比较集。使用 rg --files 和仓库的忽略规则。排除依赖项、供应商代码、缓存、生成文件、压缩文件、构建产物和覆盖率输出,除非某个文件明确属于审查范围。
    • 列出已更改或已审查的函数、类、验证与授权规则、状态转换、请求或查询构造、错误处理,以及具有明显特征的字面值,例如 URL、路由、超时、重试次数、阈值、正则表达式、功能标志和错误消息。
    • 在比较集中搜索完全匹配和近似匹配,然后结合上下文阅读每个匹配项。如果行为相同,则忽略名称和格式差异。如果业务规则、输入、副作用和失败行为基本相同,则将重命名或略微调整顺序的副本视为重复。
    • 仅报告有实质意义的重复:复制的实现、重复的业务或验证逻辑、存在差异的安全或状态逻辑,或重复的非平凡硬编码配置。不要仅因存在常见关键词、普通的一次性字面值、测试夹具、快照、生成文件或供应商代码而报告匹配项。
    • 对每个跨文件问题,标出两个文件的路径和行号。说明具体的维护、偏差、安全或行为风险,并建议采用明确的共享辅助函数、常量、配置源或其他单一事实来源。
    • 如果用户只提供了代码片段或特定文件,且未提供仓库上下文,请在 ## Validation 中说明无法进行跨文件验证。切勿编造仓库匹配项或行号证据。
  4. 分析风险

    • 优先关注正确性、回归、安全性、数据一致性、资源生命周期、并发和高风险测试缺口。
    • 🔴 Critical Issues 仅包含安全漏洞、数据丢失、行为错误、授权绕过或重大回归。
    • 🟡 Suggestions 仅包含可采取行动、不会阻塞且影响明确的问题,并给出修复方向。
    • 将一般的重复逻辑或硬编码配置归类为 🟡 Suggestions。将硬编码密钥或会造成可证实安全问题或行为缺陷的重复归类为 🔴 Critical Issues。
    • 不要报告个人偏好、缺乏依据的推测,或没有证据表明已触发的检查清单项目。
  5. 生成简洁报告

    • 使用英文撰写,并保留文件路径和行号,例如 src/user.ts:42。
    • 使用以下结构。保留所有严重性分类;没有问题的分类填写 None:
      ## 🔍 审查摘要
      - **状态**:`🟢 可以交付`、`🟡 建议修复`、`🔴 阻止交付` 或 `⚪ 没有可审查的更改`
      - **范围**:已检查的文件或更改。
      
      ## 🔴 严重问题
      - **位置**:`path:line`
        - **问题**:具体的行为缺陷。
        - **影响**:可验证的后果。
        - **修复方案**:具体的修复方向;仅在有助于说明修复方案时附上代码。
      
      ## 🟡 建议
      - **位置**:`path:line`
        - **类型**:重复逻辑、重复的硬编码值或其他适用类别。
        - **依据**:匹配的位置,以及各文件中相关的行为或值。
        - **建议**:具体且不影响交付的改进。
      
      ## 🟢 优点
      - 仅列出有更改直接支持的优点。
      
      ## 验证
      - 说明跨文件比较的范围,以及无法获取的仓库上下文。
      - 列出已执行的测试、构建和检查,并注明未运行的项目。
      
  6. 执行交付门槛

    • 如果自动审查发现 🔴 严重问题、无法确定审查范围或无法加载技能,则不要宣告完成或移交。
    • 修复发现的问题后,重新运行所需检查并再次审查更改。

评论

支持 Markdown