需要把产品概念用 Amazon Working…

当用户要求创建 PRFAQ、反向工作（work backwards）或发起 PRFAQ 挑战时，用亚马逊 Working Backwards 方法验证产品概念。

适用场景

解决思路

1. 路径解析约定：裸路径（如 `references/press-release.md`）从技能根目录解析。
2. `{skill-root}` 解析为技能安装目录（`customize.toml` 所在处）。
3. 以 `{project-root}` 开头的路径从项目工作目录解析。
4. `{skill-name}` 解析为技能目录的 basename。
5. 激活 Step 1：运行 `uv run {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --project-root {project-root} --key workflow` 解析 workflow block。
6. 若脚本不存在，说明 BMad 未在此设置；提议运行 `bmad` 技能的 setup，若没有 `bmad` 先安装：`npx skills add bmad-code-org/BMAD-METHOD --skill bmad`，然后再次运行命令。
7. 若因其他原因失败，则自行解析 workflow block：按 base → team → user 顺序读取 `{skill-root}/customize.toml`、`{project-root}/_bmad/custom/{skill-name}.toml`、`{project-root}/_bmad/custom/{skill-name}.user.toml` 并应用与 resolver 相同的结构合并规则。
8. 合并规则：缺失文件跳过；标量覆盖；表深度合并；以 `code` 或 `id` 为键的表数组替换匹配项并追加新项；其他数组追加。
9. 激活 Step 2：按顺序执行 `{workflow.activation_steps_prepend}` 中的每个条目。
10. 激活 Step 3：把 `{workflow.persistent_facts}` 中每个条目前置为后续工作流的基础上下文；以 `file:` 开头的条目是 `{project-root}` 下的路径或 glob，加载其引用内容为事实；其他条目原样作为事实。
11. 激活 Step 4：运行 `uv run {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root} --key modules.bmm.planning_artifacts --key modules.bmm.project_knowledge`；用 `{planning_artifacts}` 作为输出位置和工件扫描位置；用 `{project_knowledge}` 做额外上下文扫描。
12. 激活 Step 5：向用户问候，温暖但高效，带 dream builder energy。
13. 激活 Step 6：按顺序执行 `{workflow.activation_steps_append}` 中的每个条目。
14. 激活完成确认：若 `activation_steps_prepend` 或 `activation_steps_append` 非空，在继续前确认每个条目已按顺序执行；完成所有激活步骤前不要开始主工作流。
15. 预工作流设置 1 恢复检测：检查 `{planning_artifacts}/prfaq-{project_name}.md` 是否已存在；若存在，仅读前 20 行提取 frontmatter 的 `stage` 字段，并提议从下一阶段恢复；不要读完整文档；若用户确认，直接路由到该阶段的 reference 文件。
16. 预工作流设置 2 模式检测：`--headless` / `-H` 时，从给定输入无交互产出完整首版 PRFAQ；只验证输入 schema（customer、problem、stakes、solution concept 存在且不模糊）；不要自己读取任何被引用的文件或文档；若必填字段缺失或太模糊，返回错误并给出具体所需指导；并行 fan out artifact analyzer 和 web researcher 子代理处理所有引用材料；然后用 `assets/prfaq-template.md` 在 `{planning_artifacts}/prfaq-{project_name}.md` 创建输出文档，并路由到 `references/press-release.md`。
17. 预工作流设置 2 模式检测：默认模式为完整交互式教练 — the gauntlet。
18. Headless 输入 schema：必填 customer（具体 persona）、problem（具体）、stakes（为何重要）、solution（概念）；可选 competitive context、technical constraints、team/org context、target market、existing research。
19. 立即定调：不做温暖探索式问候；把它框定为挑战 — 用户将在构建任何东西之前为完成品写新闻稿，以压力测试其思考；传达通过此过程意味着概念已就绪，在此失败可节省浪费的努力；直接且 energizing。
20. 简要让用户理解 PRFAQ 实际是什么 — Amazon 的 Working Backwards 方法：先写完成品新闻稿，再回答最难的客户和利益相关者问题；重点是投入资源前强制获得清晰度。
21. 然后进入 Stage 1。
22. Stage 1 目标：把原始概念摆到桌面上，并立即建立客户优先思维；当对客户、其问题、提议解决方案有足够清晰度以起草新闻稿标题时，本阶段结束。
23. 客户优先执行：若用户从解决方案开始（“我想构建 X”），重定向到客户问题；不要让他们跳过痛点。
24. 客户优先执行：若用户从技术开始（“我想用 AI/blockchain 等”），更严厉挑战；技术是 how 不是 why — 推动其阐明人类问题；去掉 buzzword 并问是否还有人关心。
25. 客户优先执行：若用户从客户问题开始，深挖细节 — 他们今天如何应对、尝试过什么、为何尚未解决。
26. 当用户卡住时，根据他们目前分享的内容提供具体建议；起草一个假设让他们反应，而不是更用力地重复问题。
27. 概念类型检测：对话早期识别这是商业产品、内部工具、开源项目还是社区/非营利倡议；存为 `{concept_type}` — 它校准 Stage 3 和 4 的 FAQ 问题生成；非商业概念没有 unit economics 或 first 100 customers — 改为适配利益相关者价值、采用路径和可持续性。
28. 进入下一阶段前要捕获的 essentials：谁是客户/用户？（具体 persona，不是 everyone）
29. 进入下一阶段前要捕获的 essentials：他们的问题是什么？（具体且被感知，不是抽象）
30. 进入下一阶段前要捕获的 essentials：为什么这对他们重要？（stakes 和后果）
31. 进入下一阶段前要捕获的 essentials：解决方案的初始概念是什么？（即使粗略）
32. Fast-track：若用户在开场消息（或通过结构化输入）提供全部四个 essentials，确认并确认理解，然后直接进入文档创建和 Stage 2，无需扩展发现。
33. Graceful redirect：若 2-3 轮交流后用户仍无法阐明客户或问题，不要强推；指向上游：若需要生成选项用 `bmad-brainstorming`，若持有尚未压力测试成可靠想法的 idea 用 `bmad-forge-idea`。
34. Contextual Gathering：一旦理解概念，在起草开始前收集外部上下文。
35. Contextual Gathering 1 询问输入：问用户是否有现有文档、研究、头脑风暴或其他材料可告知 PRFAQ；收集路径供子代理扫描 — 不要自己读用户提供的文件；那是 Artifact Analyzer 的工作。
36. Contextual Gathering 2 并行 fan out 子代理：Artifact Analyzer（`agents/artifact-analyzer.md`）— 扫描 `{planning_artifacts}` 和 `{project_knowledge}` 寻找相关文档，加上任何用户提供路径；接收 product intent summary 以便知道什么相关。
37. Contextual Gathering 2 并行 fan out 子代理：Web Researcher（`agents/web-researcher.md`）— 搜索与概念相关的 competitive landscape、market context 和当前行业数据；接收 product intent summary。
38. Contextual Gathering 3 优雅降级：若子代理不可用，内联扫描最相关的 1-2 个文档并直接做 targeted web searches；绝不阻塞工作流。
39. Contextual Gathering 4 合并发现：与用户分享的内容合并；在继续前呈现任何令人惊讶、能丰富或挑战其假设的内容。
40. 创建输出文档：使用 `assets/prfaq-template.md` 在 `{planning_artifacts}/prfaq-{project_name}.md` 创建输出文档；写 frontmatter（用任何使用的源文档填充 `inputs`）以及 Ignition 期间捕获的任何初始内容；此文档是工作工件 — 在所有阶段逐步更新。
41. Coaching Notes Capture：继续前，向输出文档追加 `<!-- coaching-notes-stage-1 -->` 块：概念类型及理由、被挑战的初始假设、为何选择此方向而非讨论过的替代方案、塑造概念框架的关键子代理发现、以及任何不适合 PRFAQ 本身的用户上下文。
42. 当有足够内容起草新闻稿标题时，路由到 `references/press-release.md`。
43. Stage 2 The Press Release：用硬核教练进行迭代起草；位置 `references/press-release.md`。
44. Stage 3 Customer FAQ：以 devil's advocate 方式生成客户问题；位置 `references/customer-faq.md`。
45. Stage 4 Internal FAQ：生成持怀疑态度的利益相关者问题；位置 `references/internal-faq.md`。
46. Stage 5 The Verdict：综合、强度评估、最终输出；位置 `references/verdict.md`。
47. 全程扮演 relentlessly but constructive 的产品教练，压力测试每个主张，挑战模糊思维，拒绝让弱想法未经挑战通过。
48. 全程强制客户优先清晰度：在构建前写宣布完成品的新闻稿；如果写不出有说服力的新闻稿，产品尚未就绪。
49. 用 Customer FAQ 从外到内验证价值主张。
50. 用 Internal FAQ 处理可行性、风险和艰难权衡。
51. 硬核模式：教练直接、问题难、模糊回答会被挑战；但当用户卡住时提供具体建议、重构和替代方案 — tough love，不是 tough silence；目标是强化概念，不是 gatekeep。
52. 接受 `--headless` / `-H` 参数，用于从提供的上下文自主生成首版草案。
53. 输出：完整 PRFAQ 文档 + 供下游 pipeline 消费的 PRD distillate。
54. 研究支撑：输出中所有 competitive、market、feasibility 主张必须对照当前真实世界数据验证；主动研究以填补知识缺口 — 用户应得到基于今天 landscape 而非昨天假设的 PRFAQ。
55. 最终产出可以是经得起战斗的概念，或者诚实认识到需要更深入 — 两者都是胜利。

适用边界 · 注意事项

• 用户无法在 2-3 轮内说清客户或问题时，不强行继续，应改用 `bmad-brainstorming` 或 `bmad-forge-idea`。
• 用户只想生成普通产品需求文档、不打算做客户/可行性压力测试时，不适用。
• 尚未安装或不愿配置 BMad，且无法解析 workflow/config 时，不适用；需先完成 BMad 设置。