Brian
8b4da79161
* refactor: group v6 deprecation shims into v6-shims folders Move the nine backward-compatibility forwarders into dedicated v6-shims/ folders so the deprecation set is visible in one place and can later be made an install-time include/exclude option before removal at the v7 cut. core-skills/v6-shims/: the five review and editorial husks bmm-skills/v6-shims/: the four PRD and architecture husks Grouping only — no content changes. The installer discovers skills by a recursive walk and installs each under its own name, so installed paths and skill IDs are unchanged. Verified by diffing a full headless install against main: identical .claude/skills listing and file content, and an identical _bmad tree. The only delta is the path column in skill-manifest.csv, which now records the new source location. External module repos (gds, loop, tea, bmb, os-utils) and enterprise users still invoke these IDs, so they continue to ship by default. * refactor(core): merge editorial review into bmad-review as lenses All reviews are reviews. bmad-editorial-review's two passes become two more bmad-review lenses, leaving one lens runtime instead of two skills with overlapping trigger descriptions — "review this document" matched both before, so which one ran was close to arbitrary. Lenses now declare what they apply to. applies_to is "code", "docs", or "any", and is the first filter on a default review; `when` still refines it in prose. adversarial stays "any" — it is a stance, not a subject- matter method, and is the lens a code/doc skill split could not have placed. edge-case-hunter's `when` was "always", which is why it would have fired on prose; it now gates on having a behavioral surface. A lens may also declare `after`, naming a lens it builds on: prose runs on top of the structure findings, as it always has. The runner announces the plan, runs the independent lenses (in parallel via subagents when available), then the dependent ones on their results. Lens wording is unchanged. The three code lens files are byte-identical; the editorial passes moved verbatim into references/lens-structure.md, references/lens-prose.md, and references/editorial-common.md, which carries what both share — the content-sacrosanct rule, style guide handling, reader calibration, and the findings table. That material used to load unconditionally; as lenses it loads just-in-time, so a code review no longer pays for it. bmad-editorial-review becomes the sixth v6 shim, forwarding with the structure and prose lenses named. It keeps its customize.toml so existing team and user overrides still resolve, and forwards them as pre-resolved values. The four other husks now name bmad-review and their lens explicitly. Each still pins its own legacy output contract. bmm's four document skills point doc_standards at the merged skill with named lenses. Docs updated across all five locales. Core is 7 skills. A headless install produces the same 47-skill set as main, with all six shims resolving. * fix(core): honor forwarded customization and de-hardcode the lens set Follow-up to the editorial/review merge, from review of #2608. Contract fixes: - bmad-review gains a Forwarded activation clause matching bmad-prd and bmad-architecture, so the bmad-editorial-review shim's pre-resolved fields are honored instead of being silently overwritten by the skill's own customize.toml. Existing bmad-editorial-review overrides resolve again. - The announce step is skipped when a caller pinned an exact output contract, and a forwarder's contract now governs everything emitted rather than the findings block alone. The edge-case (raw JSON) and verification-gap (one exact line) forwarders no longer get a prose line prepended. Lens set is no longer hardcoded: - The description and body intro present the shipped lenses as examples and point at whatever {workflow.lenses} resolves to. Docs carry a matching note in all five locales. Also: - Document the `lenses=` directive form in Inputs and in the four bmm doc_standards comments that use it. - module-help.csv review row rewritten to the house "Use to..." convention, naming the reviewable content types and the situations that should trigger a suggestion. - Shim customize.toml trimmed to a lean legacy-key surface with empty defaults, so unset keys fall through to bmad-review and project-context.md is no longer loaded twice. - Redundant `when` clauses dropped where applies_to already encodes the rule. - Core skill count corrected to seven/four and the edge-case applies_to cell fixed to match its actual value, across all five locales.
8.7 KiB
title, description, sidebar
| title | description | sidebar | ||
|---|---|---|---|---|
| 核心工具 | 核心模块内置 skills 参考。 |
|
每个 BMad 安装都包含 核心模块 —— 一小组跨项目、跨模块、跨阶段通用的 skills。本页覆盖这 7 个核心 skills：4 个内核工具，加上 3 个 思考类 skills（brainstorming、forge idea、party mode）。
:::tip[快速入口]
在 IDE 中直接输入工具 skill 名（例如 bmad-help）即可调用，无需先加载智能体。
:::
概览
核心模块（始终安装）：
| 工具 | 主要用途 |
|---|---|
bmad-help |
基于项目上下文推荐下一步 |
bmad-advanced-elicitation |
通过多轮技法增强 LLM 输出 |
bmad-review |
多视角批判性审查 —— 对抗、边界条件与验证缺口 |
bmad-customize |
创建并验证 BMad 自定义覆盖 |
思考类 skills：
| 工具 | 主要用途 |
|---|---|
bmad-brainstorming |
引导式头脑风暴与想法扩展 |
bmad-forge-idea |
压力测试一个想法，直到它站得住、被证实或低成本地淘汰 |
bmad-party-mode |
多智能体协作讨论 |
:::note[迁移与移除]
bmad-spec 现随 BMM 模块作为第 2 阶段规划 workflow 发布 —— 见工作流地图。bmad-shard-doc 与 bmad-index-docs 已移除。原 bmad-editorial-review、bmad-editorial-review-prose、bmad-editorial-review-structure、bmad-review-adversarial-general、bmad-review-edge-case-hunter、bmad-review-verification-gap 已全部合并进 bmad-review，其编辑视角取代了原独立的编辑审查 skill；旧 ID 仍可通过转发器解析，保持兼容。
:::
bmad-help
定位： 你的默认导航入口，告诉你“下一步该做什么”。
适用场景：
- 刚完成一个 workflow，不确定如何衔接
- 新接触项目，需要先看当前进度
- 变更模块后，想知道可用能力和推荐顺序
工作机制：
- 扫描已存在产物（PRD、architecture、stories 等）
- 检测已安装模块及其可用 workflow
- 按优先级输出“必需步骤 + 可选步骤”
输入： 可选自然语言问题（如 bmad-help 我该先做 PRD 还是 architecture？）
输出： 带 skill 名称的下一步建议列表
bmad-advanced-elicitation
定位： 对已有 LLM 输出做第二轮深挖与改写强化。
适用场景：
- 结果“看起来对”，但深度不够
- 想从多个思维框架交叉审视同一内容
- 想按名字调用已知方法 —— 苏格拉底式、第一性原理、事前验尸、红队
工作机制：
- 默认针对会话中最近一次输出，也可指向其他内容
- 给出与内容匹配的候选技法短菜单
- 应用所选技法进行强化
- 交回改进版本，调用方流程从暂停处继续
输入： 待增强内容（默认最近输出），可选指定方法名
输出： 增强后的内容版本
bmad-review
定位： 面向任意 diff、文档或产物的多视角审查。统一输出。零发现是合法结果，绝不为“看起来彻底”而凑数。每个视角声明其适用对象：diff 触发代码视角，文档触发编辑视角。
内置视角：
| 视角 | 适用于 | 方法 |
|---|---|---|
| 对抗（Adversarial） | 任意内容 | 假设问题存在的怀疑式审查 —— 主动找缺失，而非只纠错 |
| 边界条件（Edge case） | 任意内容 | 走遍定义了行为的内容中的每条分支路径与边界条件 |
| 验证缺口（Verification gap） | 代码 | 找出可能回归且缺乏可靠验证兜底的行为变更 |
| 结构（Structure） | 文档 | 提出删减、合并、移动与精简 —— 文档的结构是否服务于其目的？ |
| 文字（Prose） | 文档 | 针对妨碍理解的表达问题做文字编辑 |
两个编辑视角视内容为不可侵犯：只审组织与表达，从不质疑观点；只提建议，不直接改写。两者同时选中时，文字视角在结构视角的发现之上运行。
这套视角并非固定：customize.toml 覆盖可以新增视角或替换内置视角，审查会运行解析后实际生效的那些。
工作机制：
- 加载内容，识别类型（diff、文件、函数或文档）以及属于代码还是文档
- 选择视角：你指定的，或所有适用性与条件匹配的已启用视角
- announce 执行计划 —— 将运行哪些视角，以及哪些视角在其他视角的发现之上运行
- 独立视角先运行 —— 平台支持时通过子代理并行 —— 随后运行依赖它们的视角
- 汇总为一个 findings 列表；视角间重叠是信号而非重复
输入： content（必填），lenses（可选，默认运行所有适配内容的视角），also_consider（可选），style_guide / reader_type（可选，供编辑视角使用）
输出： JSON findings 数组和/或按视角分组的 markdown 报告。可通过 skill 的 customize.toml 增加自定义视角，或调整/停用内置视角
bmad-customize
定位： 无需手写 TOML，即可修改已安装 BMad 智能体或 workflow 的行为。
工作机制：
- 扫描已安装 BMad skills 的可自定义面
- 为你的变更选择合适的覆盖范围
- 在
_bmad/custom/下写入覆盖文件 - 验证合并后的配置
输入： 用自然语言描述想要的自定义
输出： _bmad/custom/ 下的 TOML 覆盖文件。详见如何自定义 BMad
思考类 skills
以下三个 skills 是核心模块的组成部分 —— 任何阶段、任何模块都可以借助的通用思考工具。
bmad-brainstorming
定位： 用结构化创意技法快速扩展想法池。
适用场景：
- 启动新主题，想先打开问题空间
- 团队卡在同一思路，需要外部技法打破惯性
- 需要把“模糊方向”变成可讨论候选方案
工作机制：
- 建立主题会话
- 从方法库选择创意技法
- 逐轮引导产出并记录想法
- 每 10 个想法切换创意领域，防止聚集偏差
输入： 主题或问题陈述（可附上下文文件）
输出： 自包含的 brainstorm.html 会话纪念页、可选的 brainstorm-intent.md（供下游 skills 使用）与 .memlog.md 会话记录
bmad-forge-idea
定位： 压力测试一个想法，直到它站得住、被证实或低成本地淘汰。
工作机制：
- 先确立目标，并据此调整提问方向
- 按依赖顺序一次一个问题，先摆出推荐答案供你反驳
- 每个分支引入两个角色声音 —— 一个来自已安装的角色阵容，一个由话题临时召唤
- 挑战模糊措辞，并用现有项目材料检验论断
- 以 Hardened（站住了）、Killed（淘汰）或 Clearer（更清晰）收尾，附可留存的报告
输入： 任何领域的想法 —— 功能、商业模式、研究假设、人生决定
输出： 想法站住时的 forged-idea.md 提炼稿（可选），加上每次运行的 forge-report.html
bmad-party-mode
定位： 让多个智能体围绕同一议题协作讨论。
适用场景：
- 决策涉及产品、架构、实现、质量等多视角
- 希望不同角色显式冲突并暴露假设差异
- 需要在短时间内收集多方案观点
工作机制：
- 读取已安装智能体清单
- 选取最相关的 2-3 个角色先发言
- 轮换角色、持续交叉讨论
- 使用
goodbye/end party/quit结束
输入： 讨论主题（可指定希望参与的角色）
输出： 多智能体实时对话过程