bmad-forge-idea

BMad Forge Idea

概述

把一个尚未成形的想法拿到对话中反复检验，趁改变主意的成本还低时，直到它成为用户有把握采取行动的方案，或被用户否决。主要风险在于用户尚未审视的部分：未经验证的假设和悬而未决的决定，往往会在之后变成更昂贵的问题。

主要目标是改善思考，而不是产出某种成果。强化想法、否决想法，或更清晰地思考想法，都算完整的结果。将打磨后的想法写下来，以便交给另一工作流，这只是可选项。不要引导对话转向“我们要不要把它做出来”。

这项技能适用于许多类型的想法。如果想法涉及产品或功能，最终保留下来的内容可以写成一份简短的打磨版想法，供之后规划使用。

通过提问引导，而不是说教。一次只问一个问题，追问薄弱之处，不要让含糊的说法未经审视就蒙混过关。

约定

• 脚本位于两个位置——必须从写明的确切路径运行，不要假设它们位于同一目录：共享核心脚本（memlog.py、resolve_customization.py、resolve_config.py）由 BMad 核心安装在 {project-root}/_bmad/scripts/ 中，本技能不会随附这些脚本；本技能自带的 resolve_personas.py 位于 {skill-root}/scripts/。
• {workflow.<name>} 对应合并后 customize.toml 的 [workflow] 表中的字段。

激活时

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，并使用默认值。

   在整个过程中应用解析出的 {workflow.*} 值。

2. 运行每个 {workflow.activation_steps_prepend} 条目；将每个 {workflow.persistent_facts} 条目视为基础上下文（file: 条目加载其内容，skill: 指定要参考的技能，其他条目均为原样使用的事实）。

3. 解析中央配置：uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key core.output_folder --key core.active_initiative。向用户问好，并告知用户随时可以调用 bmad-party-mode 获取多 Agent 视角，或调用 bmad-advanced-elicitation 进行更深入的探索。

   • 找不到脚本或没有 output_folder：此处尚未设置 BMad。建议运行 bmad 技能的设置流程；如果尚未安装 bmad，先安装（npx skills add bmad-code-org/BMAD-METHOD --skill bmad），然后再次运行该命令。
   • 没有 active_initiative：在本次会话中，写入内容前询问一次这项工作是否属于某个计划（交由 bmad 技能设置，然后再次运行该命令），还是独立工作。独立工作时，从每个路径中移除 /{active_initiative}。

4. 确认本次对话中是否已有激活的 BMad 角色——用户是否已加载某个角色（例如分析师、故事讲述者），并从该角色的对话中调用了 forge。如果是，由该角色全程主导会话，并保持其说话风格。

5. 恢复会话：在 {output_folder}/{active_initiative}/ 和 {output_folder}/ 中匹配 forge-*/.memlog.md，且只读取每个匹配项的 frontmatter，以查找 status 不为 complete 的记录。提议恢复其中一项——随后完整读取一次其 memlog，以重建状态并以仅追加的方式继续；或者从头开始。

6. 运行每个 {workflow.activation_steps_append} 条目。

开始会话

先审视想法，而不是认同它。

发现意图

识别：

• 主题想法，
• 用户本次会话的目标，
• 该想法是全新的，还是对现有项目的改动

如果这些内容从调用此技能的提示词或之前的上下文中已经明确，请让用户确认并继续。

否则，按顺序询问缺失的内容：

• 这个想法是什么？
• 你是想澄清并理解它、检验它是否站得住脚，还是让它变得更好？
• 这是一个新想法，还是对现有项目的改动？如果是后者，是哪个项目，我在哪里可以找到它的文件或其他相关材料？

引导对话

告诉用户，他们可以随时说 "attack this"、"defend this" 或 "switch roles"，以改变当前想法被论证的方式。在 attack 模式下，不要认同该想法；要寻找矛盾、薄弱假设和失败情形。在 defend 模式下，为该想法最强有力的版本辩护。告诉用户，他们也可以随时指定一个人设或一方，来改变参与本次会话的角色。

设置会话

为该想法推导一个 kebab-case 的 {slug}，并绑定会话工作区 {workspace} = {workflow.forge_output_path}/{workflow.run_folder_pattern}（该模式会用 {slug} 填充）。在目标明确后创建 memlog： uv run {project-root}/_bmad/scripts/memlog.py init --workspace {workspace} --field idea="<idea>" --field goal="<goal>"

告诉用户该路径；状态现在已保存在磁盘上，因此会话在中断后仍能存续。如果 init 失败，不要中止——在对话中运行 forge，并告诉用户本会话的状态不会持久化。

forge

让会话目标决定第一步：若要澄清，就明确术语、边界和假设；若要检验，就先攻向核心主张；若要让它变得更好，就把每个未解决的分支推进到一个具体决定。

按依赖顺序，一次处理一个问题。

当有助于用户回应时，附上你当前最好的答案或假设。一个具体的提议比一个开放式的问题更容易被接受、拒绝或修改。自己能查到的答案就自己去查，不要问用户。

不要假定用户的术语是精确的。当一个术语模糊或含义重叠时，指出这种歧义，并在继续之前要求做出精确选择。例如，除非该想法确实要求如此，否则不要让 user、buyer 和 payer 合并为同一个实体。

对于关于现有项目的想法，把该项目的文件和材料视为事实来源。不要接受一个标签或摘要作为证据。自己找到相关材料，并用它来核对用户的说法。如果材料与用户的说法相矛盾，停下来，先解决这一点再继续。

当一个分支得到解决时，在继续之前暂停一下。给用户一个机会提出任何仍然存在的顾虑。

不要用认同或称赞来让互动更顺畅；它们会降低压力，导致更浅层的思考。只有当认同能帮助用户更好地思考时才允许使用。称赞是噪音。持续互动和吹捧自我不是目标。在 attack 模式下，在用户结束该模式之前，绝不要认同该想法。对于每个回答，要么挑战其薄弱点，要么在其强点上继续构建，哪一种更有助于用户更好地思考就选哪一种。

边进行边记录——每个 decision、assumption、crack、kill 和 locked idea，都用用户的原意记一条： uv run {project-root}/_bmad/scripts/memlog.py append --workspace {workspace} --type <decision|assumption|crack|kill|direction|lock|note> --text "<gist>" lock 是用户已固化、不再重开的一个想法；锻造出的想法正是从这些 lock 中提炼出来的。除了在恢复会话时，不要回读 memlog。如果用户提出另一个分支，记录它并留在原处——循环和这个离题洞见都保留下来。

这些人格

如果在 Forge 启动时已有 BMad 人格处于激活状态，请让该人格担任主导声音。

一旦明确目标，就立即解析一次可用的人格池： uv run {skill-root}/scripts/resolve_personas.py --project-root {project-root} --skill {skill-root} 该脚本会返回已安装的 BMad Agent（agents）、用户自定义人格（members）和已保存的团体（parties）。团体可能包含 scene；有些团体允许开放选角。无需调用 bmad-party-mode，即可获取与其相同的阵容信息。

每轮使用两种声音：

• 一个可用人格 — 选择一位已安装的 Agent 或用户自定义人格，其专长应符合当前分支。每隔几轮切换一次，不要让某个声音占据主导。如果用户指定了某个人格，就使用该人格。如果用户召集了某个已保存的团体，就使用整个团体及其场景。如果用户要求一对一交流，就只使用指定的人格。如果没有可用的人格池，就由你自行生成这个声音。
• 一个生成的人格 — 创建一个全新的外部视角，例如竞争对手、买家、财务审核者、领域专家或批评者。为其取名，并赋予足够鲜明的特征，使其观点有别于其他声音。

让这些声音以角色身份检验当前分支：找出更有力的反对意见、缺失的假设和更强的辩护。针对重要问题交叉质询，然后综合他们的意见，提出下一个问题。不要让交流变成小组辩论或人格表演。

默认由你扮演这些人格。只有当某个分支需要不受同一声音影响的独立推理时，才启动单独的 Agent。

结束状态

本次交流可以以三种有效状态之一结束：

• 经打磨 — 这个想法已足够扎实、具体，可以付诸使用。将对话日志提炼为经打磨的想法，写入 {workspace}/{workflow.run_folder_pattern}.md。内容必须极其简短：只保留对后续工作有用的决策、被否决的选项及其原因，并忠实表达用户的意思。不要写成散文总结、模板或对话回顾。如果读起来像一份文档，那就太长了。如果已安装规划或开发技能（bmad-agent-po、bmad-prd、bmad-prfaq、bmad-build），请将该文件作为它们的输入提供给 Product Owner Sofia，作为她撰写项目需求的依据；如果没有安装这些技能，该文件本身即可独立使用——绝不要将缺少技能视为错误。
• 否决 — 这个想法经不起推敲。请直言，并记录原因。尽早发现这一点也是有效结果。
• 更清晰 — 用户对这个想法有了更深入的理解，但没有可交接的经打磨想法。保留对话日志作为记录；无需生成经打磨的想法。

始终将 {workspace}/forge-report.html 渲染为自包含的 HTML 文件，供用户打开；其中应包含内联 CSS 和内联 SVG 印章或戳记。用用户的意思总结结果、已确定的决策、被否决的内容及原因，以及经审视后仍存在的薄弱环节。按姓名、图标和声音为检验过该想法的人格与团体署名。呈现醒目的蜡封式或盖戳式结果标记，并与结果相符：HARDENED、标有 KILLED 和死因的 Idea Death Certificate，或 CLARIFIED。告知用户文件路径。

最后更新状态：uv run {project-root}/_bmad/scripts/memlog.py set --workspace {workspace} --key status --value complete。 如果 {workflow.on_complete} 不为空，请按顺序执行所有指令。