mcpField
B
bug-review

bug-review

github.com/athola测试与质量343108 次安装4 天前更新
代码仓库

关于 bug-review

面向跨语言开发者的系统化代码审查技能，用于发现缺陷并准备修复方案。它结合语言识别、可复现调查、基于证据的发现、最小补丁和验证计划。

主要功能

  1. 01根据项目清单文件识别语言
  2. 02制定复现计划并记录具体命令
  3. 03按严重性和根因记录缺陷
  4. 04准备配套测试的最小修复
  5. 05记录验证证据与剩余风险

适用场景

  1. 01审查代码以发现潜在缺陷
  2. 02调查已报告或生产环境中的问题
  3. 03在重要版本发布前检查代码
  4. 04开展安全审计

安装

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

$npx skills add https://github.com/athola/claude-night-market --skill bug-review

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

包含的文件

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

modules/
defect-documentation.md
fix-preparation.md
language-detection.md

详细介绍

Bug Review 工作流

借助语言专项知识，系统地识别并修复 Bug。

快速开始

/bug-review

验证： 使用 --help 标志运行命令，以确认命令可用。

适用场景

  • 检查代码中可能存在的 Bug
  • 收到 Bug 报告后
  • 主要版本发布前
  • 安全审计期间
  • 调查生产环境问题

不适用场景

  • 审计测试覆盖率——改用 test-review

必需的 TodoWrite 条目

  1. bug-review:language-detected
  2. bug-review:repro-plan
  3. bug-review:defects-documented
  4. bug-review:fixes-prepared
  5. bug-review:verification-plan
  6. bug-review:findings-verified

按需加载

根据需要加载更多上下文：

  • 语言检测：@include modules/language-detection.md - 清单文件启发式方法、专业知识说明、版本约束
  • 缺陷记录：@include modules/defect-documentation.md - 严重性分类、根因分析、静态分析器
  • 准备修复：@include modules/fix-preparation.md - 最小补丁、惯用模式、测试覆盖率

工作流

步骤 1：检测语言（bug-review:language-detected）

使用清单文件识别主要语言（Cargo.toml → Rust，package.json → Node 等）。

声明适合该语言生态的专业身份。

注明版本约束（MSRV、Python 版本、Node 引擎）。

按需加载：加载 modules/language-detection.md，查看详细的清单文件启发式方法。

步骤 2：规划复现（bug-review:repro-plan）

确定复现方法：

  • 单元/集成测试套件
  • 模糊测试工具
  • 手动复现命令

记录准确的命令：

cargo test -p core
pytest tests/test_api.py
npm test -- pkg

验证： 运行 pytest -v tests/test_api.py 进行验证。

记录阻碍，并在依赖项不可用时提出使用模拟对象的方案。

步骤 3：记录缺陷（bug-review:defects-documented）

逐行检查代码，并为每个 Bug 记录：

  • 文件:行号引用：准确位置
  • 严重性：严重、高、中、低
  • 根因：逻辑错误、API 误用、并发问题、资源泄漏
  • 影响：会出现什么故障以及如何发生

运行静态分析器（cargo clippy、ruff check、golangci-lint、eslint）。

使用 imbue:proof-of-work 进行可复现的记录。

按需加载：加载 modules/defect-documentation.md，查看分类详情和分析器命令。

步骤 4：准备修复（bug-review:fixes-prepared）

按照语言最佳实践，起草最小化且符合惯用风格的补丁：

  • 守卫子句（Rust：模式匹配；Python：提前返回）
  • 资源清理（Go：defer；Python：上下文管理器）
  • 错误传递（Rust：?；Go：包装错误）

按照 Red → Green 模式编写测试：

  1. 编写失败的测试
  2. 应用最小化修复
  3. 验证测试通过

按需加载：加载 modules/fix-preparation.md，查看语言特定模式和测试策略。

步骤 5：制定验证计划（bug-review:verification-plan）

应用修复后执行复现步骤。

收集证据：

  • 测试输出日志
  • 基准对比结果
  • 覆盖率报告

使用 imbue:diff-analysis/modules/risk-assessment-framework 记录剩余风险。

为后续事项指定负责人和截止日期。

步骤 6：验证发现有据可依（bug-review:findings-verified）

将缺陷写入 .review/findings.json，运行引用验证器 （Skill(imbue:review-core) 第 5 步），并删除验证器驳回的条目，或将其标记为 UNVERIFIED。

缺陷分类（简要）

严重性：严重（崩溃/数据丢失）→ 高（功能故障）→ 中（用户体验下降）→ 低（边缘情况）

根因：逻辑错误 | API 误用 | 并发问题 | 资源泄漏 | 验证缺失

输出格式

## Summary
[Brief scope description]

## Defects Found
### [D1] file.rs:142 - Title
- Severity: High
- Anchor: `verbatim source text at file.rs:142`
- Root Cause: Logic error
- Impact: Data corruption possible
- Fix: [description]

## Proposed Fixes
### Fix for D1
[code diff with explanation]

## Test Updates
[new/updated tests with Red → Green verification]

## Evidence
- Commands executed
- Logs and outputs
- External references

验证： 运行 pytest -v，确认测试通过。

最佳实践

  1. 基于证据：每项发现都有文件和行号引用
  2. 可复现：清楚列出每个 Bug 的复现步骤
  3. 最小修复：以最小改动修复问题
  4. 测试覆盖：每项修复都有对应测试
  5. 风险意识：按严重程度评分并记录剩余风险

退出标准

  • 所有缺陷均已记录，并附有精确引用
  • 每项缺陷都包含 file:line 和逐字引用的 Anchor，且 citation_verifier.py 已确认所有引用（退出代码为 0），或未验证的缺陷已删除或标记为 UNVERIFIED
  • 已准备好修复方案，并确认测试覆盖
  • 验证计划包含命令和预期输出
  • 已评估剩余风险，并指派负责人

评论

支持 Markdown