AI 技能人工智能开发工具【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD点击查看免费下载BMad MethodBreakthrough Method for Agile AI Driven Development的定制区域允许组织在不修改任何已安装文件、不 Fork 任何技能的前提下把整个方法体系调教成自己的开发规范。本文围绕官方指南 docs/ko-kr/how-to/expand-bmad-for-your-org.md 的六种定制配方展开读完你将掌握三层覆盖模型的落点选择、persistent_facts/on_complete/external_sources等核心字段的完整写法以及如何通过中央配置改变房间里坐着谁从而在不接触 BMad 源码的情况下支撑绝大多数企业级需求。前置条件与配方应用方式在动手之前请先确认以下三项前提它们与 定制 BMad 指南 一脉相承项目已安装 BMad参考 安装 BMad工作区中存在_bmad/目录已理解定制模型三层覆盖与结构合并规则详见 如何定制 BMad系统中PATH里有 Python 3.11用于合并验证脚本仅依赖标准库tomllib无需pip install。:::tip[如何应用这些配方] 文中的**技能级配方配方 1-4**可以通过运行bmad-customize技能并描述你的意图来落地该技能会帮你选择正确的覆盖区域、生成覆盖文件并验证合并结果。而配方 5 这类修改中央配置的覆盖位于 v1 技能范围之外需要你手动编写。本文的配方回答的是覆盖什么的问题bmad-customize则负责在代理与工作流层面指导如何应用。 :::三层覆盖模型先选对落点选择配方之前先记住覆盖发生在哪一层。三个层次及其范围如下层次覆盖位置作用范围代理层如 Amelia、Mary、John_bmad/custom/bmad-agent-{role}.toml的[agent]段随该代理的全部工作流一起生效工作流层如产品简报、PRD 生成_bmad/custom/{workflow-name}.toml的[workflow]段仅对该次工作流执行生效中央配置_bmad/custom/config.toml的[agents.*]、[core]、[modules.*]决定代理名册谁在派对模式、回顾、需求提取中可用与组织级安装设置经验法则一条规则应适用于工程师的全部开发工作就定制开发者代理只应在写产品简报时生效就定制产品简报工作流要改变房间里坐着谁改名代理、添加自定义声音、强制共享产出物路径就编辑中央配置。源码印证三层合并的真实机制三层覆盖并非文档里的抽象说法仓库中的 config_utils.py 直接实现了它。load_customization(project_root, skill_dir)按严格顺序合并三层 TOML技能自带的customize.toml必需层团队覆盖_bmad/custom/{skill-name}.toml个人覆盖_bmad/custom/{skill-name}.user.toml。合并规则由structural_merge执行标量覆盖override wins、普通数组追加append、带code/id键的表格数组按键替换/追加。例如persistent_facts这类追加数组团队与个人两层各自添加的事实会全部生效而brief_template、on_complete这类标量覆盖值会整体替换默认值。合并后的结果通过 resolve_customization.py 输出为 JSON供技能在激活时读取。测试用例 test_resolve_customization.py 验证了家庭安装的技能也能正确读取项目覆盖_bmad/优先于更近的.git目录等关键行为。配方 1让规则覆盖代理运行的全部工作流使用场景让某个代理运行的所有工作流继承一致的工具使用规则与外部系统集成规则。这是影响力最大的模式。示例Amelia 开发者代理总是用 Context7 查库文档在史诗列表找不到故事时用 Linear 作为备选路径。# _bmad/custom/bmad-agent-dev.toml [agent] # 每次激活时都会加载并传递到 Amelia 运行的所有技能 # build、code-review、qa-generate 等 persistent_facts [ 查找 React、TypeScript、Zod、Prisma 等库的文档时先调用 context7 MCP 工具mcp__context7__resolve_library_id随后 mcp__context7__get_library_docs不要依赖训练数据里的知识。优先采用比记忆更新的文档。, 在 {planning_artifacts}/epics-and-stories.md 中找不到故事引用时先按故事 ID 或标题调用 mcp__linear__search_issues 搜索 Linear再向用户确认。有匹配项就以该条目为正式故事来源。, ]为什么有效仅这两句话就能改变组织所有开发工作流的行为。无需为每个工作流重复同样的内容也不必修改技能源码。新克隆仓库的工程师会自动遵循这套惯例。团队文件 vs 个人文件bmad-agent-dev.toml提交到 git作用于整个团队bmad-agent-dev.user.toml被 git 忽略在团队规则之上叠加个人偏好。这一分工与 config_utils.py 中团队层→用户层的合并顺序一一对应bmad技能安装时还会在_bmad/custom/.gitignore中写入*.user.toml见 setup.py 的CUSTOM_GITIGNORE常量从机制上防止个人文件被提交。配方 2在特定工作流内强制组织惯例使用场景确保工作流输出的内容满足合规、审计与后续使用者的要求。示例让所有产品简报包含合规字段并让代理遵循组织的发布惯例。# _bmad/custom/bmad-product-brief.toml [workflow] persistent_facts [ 每份简报都必须包含 所有者、目标发布版本、安全评审状态 字段。, 非商业简报内部工具、研究项目仍须包含用户价值章节但可以省略市场差异化章节。, file:{project-root}/docs/enterprise/brief-publishing-conventions.md, ]实际发生的机制事实列表在工作流激活的第 3 步加载。代理撰写产品简报时会参考必备字段与企业的惯例文档。默认技能自身没有持久事实因此这里只会加载你指定的条目。不过该键采用追加式合并而非替换所以团队层与用户层各自添加的事实都会生效见 bmad-product-brief/customize.toml 中persistent_facts的注释说明。注意persistent_facts每条可以是字面句子、file:前缀路径支持 glob内容加载后作为事实或skill:前缀引用。配方 3把完成的产出发布到外部系统使用场景工作流产出完成稿后自动发布到企业记录系统Confluence、Notion、SharePoint并打开后续任务Jira、Linear、Asana。示例产品简报自动发布到 Confluence并可选地提议创建 Jira 史诗。# _bmad/custom/bmad-product-brief.toml [workflow] # 结束钩子。标量值覆盖会整体替换空默认值。 on_complete 发布并提议后续任务 1. 读取上一步定稿的简报文件路径。 2. 用以下参数调用 mcp__atlassian__confluence_create_page - space: PRODUCT - parent: Product Briefs - title: 简报标题 - body: 简报的 Markdown 内容 记录返回的页面 URL。 3. 告知用户简报已发布到 Confluenceurl。 4. 询问要为这份简报创建 Jira 史诗吗 5. 用户同意后用以下参数调用 mcp__atlassian__jira_create_issue - type: Epic - project: PROD - summary: 简报标题 - description: 简短摘要与 Confluence 页面链接 报告史诗的 key 与 URL。 6. 不同意则干净地结束。 任一 MCP 工具失败时报告失败并输出简报路径 请用户手动发布。 为什么用on_complete而不是activation_steps_appendon_complete在工作流的主产出写完之后、最后一步精确执行一次——这正适合产出物发布。而activation_steps_append会在工作流开始干活之前、每次激活时执行。在 bmad-product-brief/customize.toml 中on_complete被定义为工作流完成时告知用户简报就绪之后执行接受字符串标量或按顺序执行的指令数组bmad-prd、bmad-retrospective等工作流同样暴露该字段。权衡取舍Confluence 发布是非破坏性操作完成时总是执行Jira 史诗创建会对整个团队可见并产生冲刺规划信号因此用用户确认来控制安全的回退路径MCP 工具失败时不要静默丢弃产出而是交给用户处理。配方 4替换为组织自己的输出模板使用场景默认输出结构与组织的预期格式不符或同一仓库里的不同组织需要不同模板。示例让 product-brief 工作流使用组织维护的模板。# _bmad/custom/bmad-product-brief.toml [workflow] brief_template {project-root}/docs/enterprise/brief-template.md工作机制工作流的 customize.toml 默认提供brief_template assets/brief-template.md相对于技能根目录。覆盖值指向{project-root}下的文件代理便在第 4 步读取组织模板而非默认模板。默认模板 assets/brief-template.md 的开头明确写着积极适配产品、目的与领域删去不配位的章节、增加产品需要的章节——代理会适应模板定义的结构而不是逐字照抄。模板编写建议将模板放在{project-root}/docs/或{project-root}/_bmad/custom/templates/与覆盖文件一起纳入版本管理沿用内置模板的结构惯例章节标题、frontmatter代理能更快适应多组织仓库中可以用.user.toml让各团队不改动已提交的团队文件、各自指向自己的模板。同类替换还适用于prd_template、validation_checklist_template见 bmad-prd/customize.toml等所有暴露模板路径的标量字段。配方 5定制代理名册使用场景不改源码、不 Fork就能改变bmad-party-mode、bmad-retrospective、bmad-advanced-elicitation等名册型技能里谁在房间里。三种常见变体如下。5a. 组织级代理品牌重塑每个真实代理都有安装程序在模块中合成的描述符。覆盖它就能改变所有使用名册的技能对该代理的称呼与呈现方式。# _bmad/custom/config.toml已提交 - 作用于所有开发者 [agents.bmad-agent-analyst] description 注重合规的业务分析师 Mary - 遵循 Porter 与 Minto 的思维方法但重视 FDA 审计追踪。像展示案卷的法医调查员一样说话。派对模式会用新描述生成 Mary。代理激活本身不受影响因为 Mary 的行为存在于技能专属的customize.toml中。这个覆盖改变的是外部技能如何感知与介绍 Mary而非她内部的工作方式——这正是 roster.py 中apply_central_agents的逻辑中央配置的[agents.code]表叠加在扫描结果之上而代理的 name/title/icon 由名册与技能定制决定已记录的默认值不会撤销定制后的名称。5b. 添加虚拟或自定义代理即使没有技能文件夹仅凭完整描述符也足以让名册型功能工作。这在派对模式或头脑风暴中增加人格多样性时尤其有用。# _bmad/custom/config.user.toml个人使用 - 被 git 忽略 [agents.spock] team startrek name 斯波克指挥官 title 科学官 icon description 逻辑优先抑制情绪。以很有趣。开启观察。从不虚张声势。为依赖直觉的主张提供反面观点。 [agents.mccoy] team startrek name 伦纳德·麦考伊博士 title 首席医务官 icon ⚕️ description 乡村医生的温情与有限的耐心。天哪吉姆我是医生不是___。 以伦理为中心平衡斯波克。向派对模式说邀请企业号船员它会按team startrek过滤并生成斯波克与麦考伊。需要时真正的 BMad 代理Mary、Amelia也可以坐在同一张桌子上。从实现看resolve_party.py 会把中央配置中的自定义成员与已安装代理合成一个共同体collectivecode 匹配的自定义成员覆盖已安装代理全新 code 加入池子但不会挤占默认房间——所以你可以放心地给团队添加任意人格而不改变开箱即用的派对。5c. 固定团队级安装设置安装程序会向每位开发者询问planning_artifacts路径之类的值。如果组织要求全团队使用同一值就在中央配置中固定它。开发者在本地提示中输入的旧值在配置解析时会被中央配置覆盖。# _bmad/custom/config.toml [modules.bmm] planning_artifacts {project-root}/shared/planning implementation_artifacts {project-root}/shared/implementation [core] document_output_language Englishuser_name、communication_language、user_skill_level之类的个人设置则放在每位开发者的_bmad/config.user.toml中团队文件不应触碰它们。这套分层的落点由 config_utils.py 的load_central_config固化它按_bmad/config.toml→_bmad/custom/config.toml→_bmad/custom/config.user.toml四层含安装器管理的团队基线层合并而旧的_bmad/config.user.toml是旧安装器的残留物不作为层参与test_resolve_config.py 专门验证了这一点。planning_artifacts/implementation_artifacts是 bmm 模块的路径配置v6-v7 迁移脚本 v6-v7-migration.toml 也以它们为迁移信号。为什么是中央配置代理级文件在单个代理激活时调整行为中央配置则在名册型技能查询名册时调整它们看到的内容——存在哪些代理、叫什么、属于哪个团队、仓库共识的共享安装设置是什么。用 IDE 会话文件补强全局规则BMad 定制在技能激活时加载。许多 IDE 工具会在技能运行前、每次会话开始时加载全局指令文件CLAUDE.md、AGENTS.md、.cursor/rules/、.github/copilot-instructions.md等。需要在 BMad 技能之外也得到遵守的规则应该在那些文件里重复核心要点。值得重复的情况规则重要到即使在普通聊天对话无激活技能中也应遵守训练数据默认值可能把模型带偏需要双保险规则足够简洁不会撑爆会话文件。示例把配方 1 的 dev 代理规则补进仓库的CLAUDE.md一行即可。!-- 读取库文档时先走 context7 MCP 工具mcp__context7__resolve_library_id 之后 mcp__context7__get_library_docs再依赖训练数据知识。 --这一行每次会话都会加载与bmad-agent-dev.toml定制配对让规则既覆盖 Amelia 的工作流也覆盖与助手的一般聊天。层次范围用途IDE 会话文件CLAUDE.md/AGENTS.md所有会话、技能激活前BMad 之外也必须遵守的简短普适规则BMad 代理定制代理运行的所有工作流按代理人格定制行为BMad 工作流定制单次工作流执行工作流专属输出形态、发布钩子、模板BMad 中央配置代理名册 共享安装设置房间里坐着谁、团队用哪些共享路径IDE 文件务必保持简洁精心挑选的十几行比冗长清单更有效。模型每个回合都会读它无关内容一多重要指令就被淹没。配方 6高级集成模式一些 BMad 工作流提供了比配方 1-5 更宽的设置区域。按需引用的知识源、自动输出发布、完成时文档标准、可替换模板等模式出现在多个工作流中。具体暴露哪些字段以各工作流的customize.toml为准。下面的示例使用字段齐全的bmad-prd但同样的模式适用于一切暴露对应字段的工作流。按需引用的知识源external_sources把工作流连接到内部知识库、竞品数据库、合规参考。代理只会在对话中确实需要相关信息时引用它们不会预先调用。# _bmad/custom/bmad-prd.toml在一切暴露 external_sources 的工作流中使用同样的模式 [workflow] external_sources [ 用户提到竞品或市场细分时起草差异化章节前先查询 corp:competitive_db(category{project_name})。, 在监管领域医疗健康、金融科技、教育中起草领域专属章节前先参考 corp:compliance_reference。, ]每条以自然语言指明 MCP 工具名、触发条件与工具所需字段。运行时若工具不存在工作流退回标准行为并告知该工具不可用。bmad-prd/customize.toml 明确区分了它与persistent_facts后者激活时加载一次、全程铭记external_sources是按需咨询的注册表只在对话浮现匹配需求时才查询。自动输出发布external_handoffs工作流完成后把定稿产出送到外部记录系统。与配方 3 的on_complete不同external_handoffs是专用的追加数组——团队条目按序累加每次交接单独执行。工具不可用则只跳过该次交接。# _bmad/custom/bmad-prd.toml在一切暴露 external_handoffs 的工作流中使用同样的模式 [workflow] external_handoffs [ 完成后用 corp:confluence_upload(space_keyPROD, parent_pagePRDs, labelprd, author{user_name}) 把 prd.md 与 addendum.md 上传到 Confluence。记录并展示返回的页面 URL。, 用 notion:create_page(database_idabc123, titlePRD: {project_name}) 在 Notion 中复制一份。, ]指定工具缺失时交接任务会被跳过并标记出来本地文件始终存在。完成时文档标准doc_standards对人读文档在完成时施加组织写作标准——内容定稿之后、用户看到输出之前。每条可以是skill:、file:或纯文本指令各评审步骤在子代理中并行执行。# _bmad/custom/bmad-prd.toml在一切暴露 doc_standards 的工作流中使用同样的模式 [workflow] doc_standards [ file:{project-root}/docs/enterprise/voice-and-tone.md, 所有日期必须使用 ISO 8601 格式YYYY-MM-DD。, 所有出现利用的地方都改为使用。, ]doc_standards是追加数组团队条目堆叠在工作流提供的默认项之上。宽结构评审应先于窄语句评审。bmad-product-brief/customize.toml 的默认值是skill:bmad-review lensesstructure,prose——先用结构透镜再做散文透镜。可替换的模板与检查清单生成结构化文档的工作流通常把模板与检查清单路径暴露为可覆盖的标量值。指向{project-root}下组织管理的文件即可在不改源码的情况下应用不同结构。# _bmad/custom/bmad-prd.toml [workflow] # 面向监管行业的 PRD 结构 prd_template {project-root}/docs/enterprise/prd-template-hipaa.md # 组织专属验证标准 validation_checklist_template {project-root}/docs/enterprise/prd-checklist-regulated.md代理会适应模板定义的结构。模板放在{project-root}/docs/或{project-root}/_bmad/custom/templates/下与覆盖文件一同做版本管理。多组织仓库里用.user.toml让各团队不改团队文件、指向自己的模板。配方组合让所有层级协同工作六种配方可以任意组合。一个真实的企业级bmad-product-brief覆盖可以在一个文件里同时设置persistent_facts配方 2、on_complete配方 3、brief_template配方 4代理级规则配方 1位于按代理名命名的独立文件中央配置配方 5固定共享名册与团队设置高级集成模式配方 6配置外部源与交接任务。所有层级同时生效。# _bmad/custom/bmad-product-brief.toml工作流层 [workflow] persistent_facts [...] brief_template {project-root}/docs/enterprise/brief-template.md on_complete ... # _bmad/custom/bmad-agent-analyst.toml代理层 - Mary 运行 product-brief [agent] persistent_facts [领域涉及医疗健康、金融、儿童数据时始终包含监管评审章节。]结果Mary 在人格激活时加载监管评审规则用户选择产品简报菜单项后工作流在其上加载自身惯例、写入企业模板、完成时发布到 Confluence。所有层级协同工作BMad 源码原封不动。问题排查覆盖不生效确认文件位于_bmad/custom/下、以精确的技能目录名命名例如bmad-agent-dev.toml而非bmad-dev.toml。可参考 如何定制 BMad 中的问题排查。不知道 MCP 工具名使用当前会话中 MCP 服务器暴露的精确名称。不确定时让 Claude Code 列出可用的 MCP 工具清单。硬编码在persistent_facts或on_complete里的名称在 MCP 服务器未连接时不会生效。模式不适合你的配置上面的配方只是示例。核心结构三层合并、结构规则、代理跨工作流行为支持的组合远不止这些按需组合即可。要点回顾覆盖有三层落点代理层该代理的全部工作流、工作流层单次执行、中央配置名册与共享安装设置由 config_utils.py 的structural_merge统一执行标量覆盖、数组追加、键控表数组按键替换persistent_facts是追加数组可写句子、file:路径支持 glob或skill:引用团队与个人事实同时生效on_complete是标量结束钩子恰好执行一次适合发布产出物external_sources按需咨询、external_handoffs独立逐条执行、doc_standards完成时评审三者生命周期各不相同名册型技能派对模式、回顾、需求提取的谁在房间里由中央配置[agents.*]决定自定义成员可通过team分组、通过 code 覆盖已安装代理团队文件.toml提交、个人文件.user.toml被 git 忽略模板与组织文档放在{project-root}/docs/或_bmad/custom/templates/一起做版本管理全程无需修改技能源码、无需 Fork——这正是 BMad 定制模型的设计意图。赞分享AI 技能人工智能开发工具【免费下载链接】BMAD-METHODBreakthrough Method for Agile Ai Driven Development项目地址https://gitcode.com/gh_mirrors/bm/BMAD-METHOD点击查看免费下载相关推荐扩展 BMad 到整个组织六种免 Fork 的企业级定制配方与三层覆盖机制深度解析扩展 BMad 到整个组织六种免 Fork 的企业级定制配方与三层覆盖机制深度解析 本文是面向组织级落地的 BMadBreakthrough MethodAI 技能人工智能开发工具BMAD-METHOD 安装指南使用 npx bmad-method install 在项目中安装与验证 BMadBMAD METHOD 安装指南使用 npx bmad method install 在项目中安装与验证 BMad BMAD METHODBreakthroAI 技能人工智能开发工具如何按组织需求 fork C Core Guidelines 并定制自己的规范副本如何按组织需求 fork C Core Guidelines 并定制自己的规范副本 如果你的目标是让团队按照组织自己的编码约定使用 C Core Gu文档教程上一篇SQL Assessment API Probe Requirements 深度解析用 requires 与 runFor 控制探针执行边界下一篇Canopy 节点交易处理与内存池Mempool机制深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考