mcpField
U
unified-review

unified-review

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

关于 unified-review

unified-review 是面向代码审查的编排技能，会分析代码库并选择适用的审查技能，适合需要多领域检查和汇总结果的团队。它支持自动检测、指定领域审查及整合问题和行动计划。

主要功能

  1. 01分析语言、结构、变更和构建系统
  2. 02按代码库特征选择审查技能
  3. 03并行执行多个审查维度
  4. 04整合并按影响排序审查发现
  5. 05生成带负责人的修复行动计划

适用场景

  1. 01合并大型功能分支前进行全面审查
  2. 02针对 API 或架构开展专项审查
  3. 03同时检查测试、错误和代码质量
  4. 04汇总多领域发现并安排后续修复

安装

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

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

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

包含的文件

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

modules/
output-format-templates.md
quality-checklist-patterns.md
review-workflow-core.md

详细介绍

统一评审编排

根据代码库分析和上下文，智能选择并执行适当的评审技能。

快速开始

# Auto-detect and run appropriate reviews
/full-review

# Focus on specific areas
/full-review api          # API surface review
/full-review architecture # Architecture review
/full-review bugs         # Bug hunting
/full-review tests        # Test suite review
/full-review all          # Run all applicable skills

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

适用场景

  • 开始全面代码评审
  • 评审涉及多个领域的更改
  • 需要智能选择评审技能
  • 希望整合多种评审类型的报告
  • 合并重要功能分支之前

不适用场景

  • 已知具体的评审类型
    • 使用 bug-review
  • test-review
  • 仅关注架构——使用 architecture-review
  • 已知具体的评审类型
    • 使用 bug-review

评审技能选择矩阵

代码库模式评审技能触发条件
Rust 文件（*.rs、Cargo.toml）rust-review、bug-review、api-review检测到 Rust 项目
API 更改（openapi.yaml、routes/）api-review、architecture-review公共 API 接口
测试文件（test_*.py、*_test.go）test-review、bug-review测试基础设施
Makefile/构建系统makefile-review、architecture-review构建复杂度
数学算法math-review、bug-review数值计算
架构文档/ADRarchitecture-review、api-review系统设计
通用代码质量bug-review、test-review默认评审
实施后审计imbue:justify新增/删除比例高、测试更改、新抽象

工作流

1. 分析仓库上下文
  • 根据扩展名和清单检测主要语言
  • 分析 git 状态和差异，确定更改范围
  • 识别项目结构（单体仓库、微服务、库）
  • 检测构建系统、测试框架和文档
2. 选择评审技能
# Detection logic
if has_rust_files():
    schedule_skill("rust-review")
if has_api_changes():
    schedule_skill("api-review")
if has_test_files():
    schedule_skill("test-review")
if has_makefiles():
    schedule_skill("makefile-review")
if has_math_code():
    schedule_skill("math-review")
if has_architecture_changes():
    schedule_skill("architecture-review")
# Default
schedule_skill("bug-review")

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

3. 执行审查

通过 Agent 工具并发分派选定的技能。 使用此映射将技能名称解析为 Agent 类型：

技能名称Agent 类型说明
bug-reviewpensive:code-reviewer涵盖缺陷、API、测试
api-reviewpensive:code-reviewer同一 Agent，侧重 API
test-reviewpensive:code-reviewer同一 Agent，侧重测试
architecture-reviewpensive:architecture-reviewerADR 合规性
rust-reviewpensive:rust-auditorRust 专项
code-refinementpensive:code-refiner重复代码、质量
math-reviewgeneral-purpose提示：调用 Skill(pensive:math-review)
makefile-reviewgeneral-purpose提示：调用 Skill(pensive:makefile-review)
shell-reviewgeneral-purpose提示：调用 Skill(pensive:shell-review)

子 Agent 隔离（必需）。 一个审查视角不得影响下一个视角的判断。可通过以下两种方式实现，第二种仅在用户提出要求时运行：

方式隔离机制
Agent 工具在一次并行调用中分派所有选定的 Agent，并在所有 Agent 返回结果前不读取任何输出。先读到的结果会使综合判断受到锚定：后续结果都会以第一个结果为参照进行评估。收齐所有结果后，再统一综合
/pensive:unified-review 工作流（workflows/unified-review.js）脚本会保存结果。它不具备推理能力，因此不会因先读某一阶段的结果而产生锚定；各阶段之间传递的发现也不会进入其他阶段的上下文。验证会按维度分别启动，无须等待最慢的审查视角

若在审查前已知维度列表，且每项发现都应接受对抗性检查，优先使用该工作流。若 Agent 列表需要根据第一个审查视角的发现进行调整，或用户未要求使用工作流，则使用 Agent 工具：工作流绝不会在未被要求时自行启动。

无论会话的权限模式如何，其子 Agent 都会在 acceptEdits 模式下运行，因此发布的脚本会将提示限定为只读操作。脚本也无法访问文件系统，因此它返回的是经反驳检验后仍成立的主张，而非工作成果的证据。采取行动前，请先复现发现的问题。

规则：

  • 切勿将技能名称用作 Agent 类型（例如，pensive:math-review 不是 Agent）
  • 若 pensive:code-reviewer 涵盖多个领域，只分派一次，并在其中合并相关范围
  • 对于没有专用 Agent 的技能，使用 general-purpose，并指示其调用 Skill 工具
  • 所有 Agent 的证据记录方式必须保持一致
  • 通过 TodoWrite 跟踪进度
4. 整合发现
  • 整合各领域的发现
  • 识别跨领域模式
  • 按影响和工作量确定优先级
  • 制定统一行动计划

延后记录待办发现： 对于被分流至待办列表的发现（不属于当前审查范围，或由团队决定延后处理），应予以保留，避免在不同审查周期之间丢失。 对于每项分配至待办列表的发现，运行：

python3 scripts/deferred_capture.py \
  --title "<finding title>" \
  --source review \
  --context "Review dimension: <dimension>. <finding description>"

<dimension> 的值应与发现该问题的审查技能一致（例如 bug-review、api-review、architecture-review）。 行动计划确定后，此步骤会自动运行，无须征求用户同意。

审查模式

自动检测（默认）

根据代码库分析自动选择技能。

专项模式

运行指定的审查领域：

  • /full-review api → 仅运行 api-review
  • /full-review architecture → 仅运行 architecture-review
  • /full-review bugs → 仅运行 bug-review
  • /full-review tests → 仅运行 test-review
全面审查模式

运行所有适用的审查技能：

  • /full-review all → 执行检测到的所有技能

质量门槛

每次审查都必须：

  1. 建立恰当的上下文
  2. 成功执行所有选定的技能
  3. 使用证据记录发现
  4. 按影响确定建议的优先级
  5. 制定包含负责人的行动计划

交付内容

执行摘要
  • 代码库整体健康状况评估
  • 需要立即处理的关键问题
  • 审查频率建议
特定领域报告
  • API 表面分析与一致性
  • 架构与 ADR 的一致性
  • 测试覆盖率缺口与改进
  • Bug 分析与安全发现
  • 性能与可维护性建议
综合行动计划
  • 按优先级排列的修复任务
  • 跨领域依赖关系
  • 指定负责人和目标日期
  • 后续审查计划

模块化架构

所有审查技能均采用中心辐射式架构，并按需渐进加载：

  • 每项技能都有 modules/：按需加载特定领域的详细信息
  • 跨插件依赖项：imbue:proof-of-work、imbue:diff-analysis/modules/risk-assessment-framework

对于专注型审查，这可减少 50-70% 的 token 使用量，同时保留完整功能。

退出标准

  • 已执行所有选定的审查技能
  • 已汇总并排定发现事项的优先级
  • 已制定明确负责人分工的行动计划
  • 已按照结构化输出格式记录证据

支持模块

故障排除

常见问题

如果自动检测未能识别正确的审查技能，请明确指定模式（例如，使用 /full-review rust，而不是仅使用 /full-review）。如果集成失败，请检查 TodoWrite 日志是否可访问，以及各项技能是否正确写入证据文件。

评论

支持 Markdown