mcpField
B
bmad-review

bmad-review

github.com/bmad-code-org测试与质量54.7k12.1k 次安装1 周前更新
代码仓库

关于 bmad-review

bmad-review 是通过可配置视角审查代码或文档的 BMad 技能。它会选择适用的视角,执行独立或依赖式审查,并按配置格式呈现发现。

主要功能

  1. 01可配置的审查视角
  2. 02审查代码与文档
  3. 03执行独立及依赖式审查
  4. 04结构化记录位置与后果
  5. 05输出 JSON 或 Markdown 报告

适用场景

  1. 01合并前审查代码差异
  2. 02检查工单或需求文档
  3. 03运行指定的编辑或对抗性审查视角

安装

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

$npx skills add https://github.com/bmad-code-org/bmad-method --skill bmad-review

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

包含的文件

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

bmod.toml
customize.toml
references/
editorial-common.md
lens-adversarial.md
lens-edge-case-hunter.md
lens-prose.md
lens-structure.md
lens-verification-gap.md
structure-models.md
scripts/
word_metrics.py
scripts/tests/
test_word_metrics.py

详细介绍

BMad Review

通过不同视角审查内容——每种视角代表一种独特的方法和立场——并以统一的规范格式报告发现。只报告真实问题,绝不要为了显得全面而凑数。每种视角都会设定其对内容以及零条发现的立场:对大多数视角而言,结果为空是有效的;对抗性视角要求至少十条具体发现,并将空列表视为需要重新检查的信号;编辑视角将内容视为不可更改,只评判其组织和表达方式。

视角集合取决于 {workflow.lenses} 的解析结果,而非固定列表——覆盖项会添加视角并替换随附的视角。不要声称具备本文件未声明的能力;请读取解析后的视角并据此开展工作。

输入

  • content — 要审查的内容:差异、分支、未提交的更改、文件、工单(计划、史诗、故事、技术调研、缺陷)或任何文档。参数:[path]。
  • lenses(可选)— 一个或多个视角代码或名称,调用者可用任意方式表达:口头请求,或 skill:bmad-review lenses=<code>[,<code>...] 形式的指令(bmm 的 doc_standards 使用此形式)。默认:所有适用的视角(完整审查)。
  • also_consider(可选)— 在每种视角的常规分析中一并考虑的方面。
  • claims(可选)— 更改本身的说明:涉及的提交消息,或调用者提供的任何描述。仅提供给边缘情况视角。
  • pre-resolved customization(可选)— 转发调用者提供的 [workflow] 字段值。请参阅执行步骤 1。

约定

  • 裸路径(例如 references/lens-edge-case-hunter.md)相对于 {skill-root} 解析——即此技能的安装目录,customize.toml 所在的位置。{project-root} 是最近的包含 _bmad/ 的文件夹,从项目工作目录开始,沿父目录向上查找。
  • {workflow.<name>} 解析为 customize.toml 的 [workflow] 表中的字段(根据 BMad 合并规则,覆盖项优先)。
  • 在 style_guide、review_guidance 和 persistent_facts 中,以 file: 为前缀的值是路径或 glob 模式——请加载该文件的内容。如果无法读取某个 file: 值,请在输出标题中注明读取失败的文件,并继续处理:style_guide 使用随附的基线,其余情况使用其他条目。

执行

  1. 解析自定义配置: uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow。
    • 找不到脚本:此处尚未配置 BMad。请提出运行 bmad 技能的设置流程;如果尚未安装 bmad,先安装(npx skills add bmad-code-org/BMAD-METHOD --skill bmad),然后再次运行该命令。
    • 其他任何失败:直接读取 {skill-root}/customize.toml,并使用默认值。 **转发激活:**如果调用方通过预先解析的自定义字段调用你(例如 bmad-editorial-review shim),请原样采用这些指定字段——它们已包含用户的覆盖设置——并且只从你自己的 customize.toml 中解析其余字段。然后按顺序执行每个 {workflow.activation_steps_prepend} 条目,将 {workflow.persistent_facts} 作为本次会话的常驻上下文,并将 {workflow.review_guidance} 条目视为适用于每个审查视角的常驻审查指令。
  2. 加载内容。将内容暂存为一个文件:如果内容是分支、未提交的工作或提交范围,请使用仓库的版本控制工具将统一差异写入系统临时目录中一个名称唯一的文件,并将该文件的绝对路径作为内容。分支是指与其基准分支的合并基准点之间的差异;未提交的工作包括未跟踪文件。以相同方式将 claims 暂存到单独的文件中——它是一个视角的输入,单独暂存正是为了确保其他视角看不到它。如果内容为空或无法解码为文本:当调用方期望原始发现结果 JSON 数组时(例如旧版边缘情况转发器),返回 [{"location":"N/A","trigger_condition":"Input empty or undecodable","guard_snippet":"Provide valid content to review","potential_consequence":"Review skipped — no analysis performed"}](不含 lens 字段)并停止;否则说明问题所在,并要求提供可审查的内容。判定内容属于哪一类——差异、源文件、函数或文档——并判断它是代码还是文档;范围规则和视角适用性都取决于此。定义行为的文档(工单、计划、需求)属于 docs,行为视角仍可能适用;请根据 when 判断。
  3. 从 {workflow.lenses} 中选择视角。instruction 为空的视角已禁用。如果用户或调用方指定了视角,则只运行这些视角——applies_to 和 when 不会筛除明确指定的请求。否则,运行所有已启用、其 applies_to 覆盖内容类别(any 始终覆盖)且其 when 条件适用的视角。
  4. 宣布计划,在开始任何操作前用一行说明内容类别、即将运行的视角,以及——只要有任何视角设置了 after——该视角将在指定视角的发现结果基础上运行。如果调用方固定了精确的输出约定(要求原始 JSON 或某一条精确内容的旧版转发器),则完全跳过此公告——其约定涵盖你输出的所有内容,而不仅是发现结果部分。然后按顺序执行每个 {workflow.activation_steps_append} 条目。
  5. 运行独立视角——所有未设置 after 的已选视角。每个视角都可以查看内容和 also_consider,但不能查看其他视角的发现结果。遵循各视角的 instruction;随附视角会按需即时加载其参考文件,因此只加载实际运行的视角所需文件。如果可以使用子代理,请先启动所有独立视角,再处理任何视角的结果。尝试同时运行:每个视角启动一个子代理;向其提供视角的 instruction(将 {skill-root} 和路径解析为绝对路径)、暂存内容文件的绝对路径(视角提示词中包含该路径,由视角读取文件,绝不传入内容字节;如果内容从未暂存为文件,则仅在这种情况下内联内容)、任何 also_consider 范围、常驻审查指令,以及仅提供给边缘情况视角的 claims 路径(并标记在指令要求读取前不得读取)。还需提供以下约束:“只返回你的发现结果——不输出任何其他内容。不要调用任何技能,也不要自行启动子代理——你是审查者。请在最终消息中以文本形式返回发现结果;不要通过主机可能提供的任何发现结果报告工具转交。”否则,由你按顺序运行这些视角,每个视角完成后再开始下一个。
  6. 运行依赖视角——所有设置了 after 的已选视角,在其指定的视角完成后运行,并传入该视角的发现结果。如果某个视角的 after 目标未被选中或没有产出结果,该视角仍须运行,但不传入先前的发现结果。指定不同目标的依赖视角彼此独立:处理其结果前,先启动所有已就绪的视角。尝试同时运行。如果可以使用子代理,请向其提供与独立视角相同的约束:“只返回你的发现结果——不输出任何其他内容。不要调用任何技能,也不要自行启动子代理——你是审查者。请在最终消息中以文本形式返回发现结果;不要通过主机可能提供的任何发现结果报告工具转交。”
  7. 根据下方的输出要求汇总并呈现。保留每个视角的所有发现结果——不同视角之间的重叠是信号,并非重复;应在 Markdown 报告中注明,不要去重。如果设置了 {workflow.on_complete},请执行。

输出

一个 JSON 数组,包含所有视角的每一条发现。每条发现包含:

  • lens — 产生该发现的视角代码
  • location — 内容中的位置(代码为 file:line-range,文档为 section)
  • trigger_condition — 问题,或暴露该问题的条件,用一行描述
  • guard_snippet — 具体的修复、防护或缺失的检查
  • potential_consequence — 若按原样发布会出现什么问题

每个视角文件会为其发现细化这些语义,并可添加视角特有的字段(例如删除类发现上的 kind/confidence,验证缺口类发现上的 gap_shape/consumer/evidence)。视角文件也可以改为声明自己的发现结构和渲染方式 —— 编辑类视角渲染一张发现表 —— 该结构对该视角的发现具有优先权。[] 在未发现任何内容时有效。任何地方都没有严重程度、优先级或排名。

按 {workflow.output_format} 呈现 —— "json"(围栏 json 代码块中的原始数组)、"markdown" 或 "both" —— 除非调用方要求了特定结构;旧版转发器的输出契约始终优先,并约束你发出的所有内容,而不仅仅是发现块。Markdown 报告按视角对发现进行分组,每个视角按其声明的结构渲染:每条发现用一个简短块渲染其字段以及值得展示的额外内容,某视角未发现任何内容时用一行说明,整个审查干净时用一句简明清晰的陈述。按 {workflow.output_preferences} 调整报告结构。

当设置了 {workflow.report_path} 时,将报告写入该路径;否则在聊天中呈现。

评论

支持 Markdown