mcpField
F
find-bugs

find-bugs

github.com/ulpi-io测试与质量5169 次安装9 周前更新
代码仓库

关于 find-bugs

面向代码审查的只读技能，用于检查分支变更并报告经证据验证的缺陷或漏洞。它要求审阅实际差异、核查上下文并按严重程度排序，不修改应用代码。

主要功能

  1. 01审阅分支差异与变更文件
  2. 02检查安全及逻辑缺陷
  3. 03验证候选问题与上下文
  4. 04按严重程度排列发现
  5. 05只读审查，不编辑代码

适用场景

  1. 01合并前审查分支变更
  2. 02检查认证或数据完整性风险
  3. 03验证疑似并发或边界问题
  4. 04记录带证据的缺陷报告

安装

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

$npx skills add https://github.com/ulpi-io/skills --skill find-bugs

安装后在 Claude Code 中输入/find-bugs确认已加载。

附带文件references/review-checklists.md

详细介绍

此技能仅用于报告，且必须以证据为依据。

不可妥协的规则：

  1. 报告发现之前，先阅读完整的分支差异。
  2. 根据周边代码和框架行为验证每项发现。
  3. 只报告真实缺陷或漏洞，不报告风格方面的看法。
  4. 工作流必须为只读。不要在使用此技能时编辑应用代码。
  5. 使用检查清单参考来系统地开展审查，但不要在每次调用时粘贴整个检查清单。

查找 Bug

输入

  • $request：可选的审查指导，例如关注领域、威胁模型或子系统提示

目标

生成可信的分支审查，并做到：

  • 阅读实际变更的代码
  • 梳理相关的攻击面和缺陷面
  • 在报告前验证发现
  • 根据严重性优先处理真实问题
  • 如果没有发现重大问题，明确说明审查结果良好

步骤 0：确定审查范围

此技能审查的是分支变更，默认不审查整个代码库。

确定：

  • 默认分支
  • 审查目标是整个分支、某个提交范围，还是用户提供的当前差异指导
  • 用户是否指定了关注领域，例如身份验证、数据完整性、并发或机密信息

如果相对于审查基准没有变更，请停止并明确说明。

成功标准：审查范围明确，并且有实际差异内容可供检查。

步骤 1：阅读实际差异和变更文件

通过以下方式检查审查范围：

  • 与默认基准分支进行分支差异比较
  • 变更文件列表
  • 根据需要使用 Read 查看变更文件的上下文

规则：

  • 阅读实际变更行，而不只是 --stat
  • 如果差异输出过大，则逐个文件与基准版本比较并阅读
  • 仅当 codemap 等嵌套辅助工具能显著改善代码发现时，才使用 Skill

成功标准：已阅读所有与审查相关的变更文件，并掌握足够上下文以进行推理。

步骤 2：梳理攻击面和缺陷面

对于每个变更文件，识别相关面：

  • 用户输入
  • 数据库查询
  • 身份验证与授权
  • 会话或令牌处理
  • 外部调用
  • 加密或机密信息处理
  • 序列化和解析
  • 文件系统路径和上传
  • 并发或状态转换
  • 边界情况和边界行为

安全风险较低的文件仍可能包含逻辑 Bug，因此不要完全跳过。

加载 references/review-checklists.md，查看完整的审查矩阵。

成功标准：根据变更文件实际暴露的风险对其进行分类。

步骤 3：运行针对性的审查检查清单

使用 references/review-checklists.md 评估：

  • 注入
  • XSS 和不安全的渲染
  • 身份验证和授权
  • 会话和 CSRF 处理
  • 竞态条件
  • 加密和机密信息处理
  • 信息泄露
  • 拒绝服务和资源耗尽
  • 业务逻辑正确性
  • 一般逻辑 Bug，例如空值访问、异步错误、边界错误和缺少返回值

规则：

  • 不要假定框架会保护某种模式；应检查保护措施是否确实适用于此处
  • 不要因为某个文件“看起来简单”就跳过检查清单中的任何部分
  • 聚焦于变更代码，但要阅读足够的周边代码以验证判断

成功标准：已根据实际变更面评估所有有意义的检查清单项目。

步骤 4：验证每项候选发现

报告问题前，请检查：

  • 周边函数和调用方上下文
  • 中间件、辅助函数或封装器是否已缓解问题
  • 现有测试是否已覆盖该场景
  • 问题在实践中是否确实可利用，或是否会导致错误行为

如果无法有把握地验证发现，请将其删除，或明确标注验证方面的不足。

不要把依据薄弱的怀疑夸大成发现。

成功标准：每项报告的问题都通过了误报检查。

步骤 5：分类并确定优先级

根据实际影响分配严重级别：

  • Critical
  • High
  • Medium
  • Low

优先处理：

  • 可利用的安全问题
  • 其次是正确性和数据完整性缺陷
  • 最后是风险较低但仍属于真实缺陷的质量问题

加载 references/review-checklists.md，获取严重级别指引。

成功标准：问题按实际风险排序，而不是按发现难易程度排序。

步骤 6：提供附带证据的报告

对于每项发现，报告：

  • File:Line
  • 严重级别
  • 类别
  • 简洁的问题说明
  • 证明问题确实存在的证据
  • 相关的利用路径或故障路径
  • 具体的修复方向

还需报告：

  • 已审查的文件
  • 检查清单覆盖情况摘要
  • 未完全验证的领域

如果没有发现重大问题，请明确说明。

成功标准：其他工程师无需从头重新推导问题，就能据此采取行动。

注意事项

  • 不要将编辑代码作为此技能的一部分。
  • 不要报告仅涉及风格的问题。
  • 不要为了显得全面而杜撰问题。
  • 不要添加 disable-model-invocation；用户要求进行主动审查时，此技能应保持可用。
  • 不要添加 paths:；这是通用工作流技能。
  • 将详尽的检查清单内容放在 references 中，而不是内联到 SKILL.md 中。

何时加载参考资料

  • references/review-checklists.md 用于详细的安全、逻辑、严重级别和报告检查清单。

输出约定

报告：

  1. 已审查的文件
  2. 按严重级别列出的发现
  3. 附带证据的简洁详细发现
  4. 检查清单覆盖情况及验证缺口
  5. 如果未发现重大缺陷，请明确说明审查结果为干净

评论

支持 Markdown