ask-mystartupproject1

name	ask-MyStartupProject1
description	为项目根目录（Windows `D:/work/MyStartupProject1`；macOS `/Users/stark/Desktop/work/MyStartupProject1`）提供 BMAD 项目总控，覆盖从 0 开始的方向筛选、需求验证、市场与竞品、中国大陆与海外机会判断、立项决策、Product Brief、MVP、架构、实施准备、开发、自动测试、发布上线、上线后复盘与版本迭代。在用户提及 /ask-MyStartupProject1、MyStartupProject1、项目方向、市场调研、竞品分析、Product Brief、MVP、路线图、架构、开发、测试、上线、迭代，或询问该用哪个 BMad 角色时使用。

ask-MyStartupProject1

作用

本技能是 <项目根目录> 的默认总控入口。

它的职责不是只回答某个点状问题，而是用 BMAD 帮用户完整推进一个项目生命周期：

• 从 找方向 到 是否立项
• 从 Product Brief / MVP 到 架构与实施准备
• 从 开发 / 自动测试 到 发布上线
• 从 上线后复盘 到 后续版本迭代

何时使用

在以下场景默认优先使用本技能：

• 新 chat：Cursor 输入 /ask-MyStartupProject1；Codex 输入 /MyStartupProject1（见 ~/.codex/skills/MyStartupProject1/SKILL.md），两者读完本节后下文规则相同
• 用户问 这个方向值不值得做
• 用户问 下一步该用哪个 BMAD 角色
• 用户要推进 竞品分析、Product Brief、MVP、路线图、架构、开发、测试、上线 或 迭代

激活后，默认先恢复本技能中的稳定规则，再读取项目主文档，判断当前处于哪个阶段、下一步该走哪个 BMAD 工作流。

Cursor / Codex 与 BMAD 子技能：ReadFile 与 @

• 路径（本文件）：Windows %USERPROFILE%\.cursor\skills\ask-MyStartupProject1\SKILL.md（本机示例：C:\Users\Stark8964911\.cursor\skills\ask-MyStartupProject1\SKILL.md）；macOS/Linux ~/.cursor/skills/ask-MyStartupProject1/SKILL.md（本机示例：/Users/stark/.cursor/skills/ask-MyStartupProject1/SKILL.md）。
• 路径（对照 Codex）：Windows %USERPROFILE%\.codex\skills\MyStartupProject1\SKILL.md（本机示例：C:\Users\Stark8964911\.codex\skills\MyStartupProject1\SKILL.md）；macOS/Linux ~/.codex/skills/MyStartupProject1/SKILL.md（本机示例：/Users/stark/.codex/skills/MyStartupProject1/SKILL.md；口令 /MyStartupProject1，~/.codex/AGENTS.md）；与本文分别维护，阶段与工作流应对齐。
• 项目根目录：Windows D:/work/MyStartupProject1；macOS /Users/stark/Desktop/work/MyStartupProject1。下文 <项目根目录> 均指当前系统对应路径。
• 新会话必读顺序（与 Codex /MyStartupProject1 一致）：
  1. 本 SKILL.md（稳定规则、路由、门禁）
  2. <项目根目录>/项目主档案.md
  3. <项目根目录>/stories/sprint-status.yaml（开发阶段优先于主档案阶段描述）
  4. 需要模板与命名规范时：Windows %USERPROFILE%\.cursor\skills\ask-MyStartupProject1\reference.md；macOS/Linux ~/.cursor/skills/ask-MyStartupProject1/reference.md

当前 chat 上下文加载门禁（必读）

• 入口恢复自检：每次新 chat 通过 /ask-MyStartupProject1 进入时，先确认本轮已经实际读取本 SKILL.md、<项目根目录>/项目主档案.md、<项目根目录>/stories/sprint-status.yaml。若用户本轮已经手动粘贴了其中部分内容，也只能视为“内容片段已知”；需要执行任务前仍优先按精确路径读取原文件，除非读取不可用。

• 任务相关文件自检：执行任何子任务前，先列出该任务必须依赖的文件类型：目标 story / epics.md / 产品与架构文档 / 相关代码 / 测试 / 配置 / 外部规则。逐项判断当前 chat 是否已经实际读取到最新内容；未读取、无法确认、只见摘要或历史结论时，先补读再执行。

• 子 skill 自检：若下一步会执行任意其他 skill（尤其 bmad-*），先判断当前 chat 是否已经实际读取该子 skill 的 SKILL.md 及其要求的 workflow.md / checklist.md / reference.md / template.md 等附属文件。缺一项就按当前系统路径补读。

• 上下文完整性优先级：宁可先补读少量关键文件，也不要基于 skill 名称、路由表、旧聊天记忆或项目主档案里的历史摘要直接执行。磁盘存在、打开标签页存在、上一轮读过，都不等于当前 chat 已加载。

• 开始执行前说明：进入代码修改、story 状态推进、BMAD 模板产出或审查前，简短说明本轮已加载的关键入口文件，以及本步新增补读的子 skill / story / 代码文件。若无需新增读取，说明“无新增”。

• 不要默认当前会话已像「勾选多个 Agent Skills」一样，静默载入每一份 bmad-*.md。下文路由里的 bmad-agent-*、bmad-* 表示应采样的角色或工作流，不等于上下文里已有对应 SKILL 全文。

• 执行任意 bmad-<identifier>（含 Cursor 内 Codex 插件）：当本步须按该工作流产出或严格遵循其专项步骤，在动手前必须 ReadFile 本机：macOS/Linux 为 ~/.cursor/skills/<bmad-identifier>/SKILL.md（或 /Users/<用户名>/.cursor/skills/<bmad-identifier>/SKILL.md）；Windows 为 %USERPROFILE%\.cursor\skills\<bmad-identifier>\SKILL.md（示例：C:\Users\Stark8964911\.cursor\skills\...）。标识与路由/文档中的 bmad-... 全文一致。并继续读取该 SKILL 指向的 workflow.md 等同目录文件。Codex 侧强制约定见 ~/.codex/AGENTS.md「BMAD 工作流与 .cursor/skills 磁盘路径」。

• 先做当前 chat 上下文自检：准备执行任意 bmad-<identifier> 前，先判断当前 chat 是否已经实际读取并保留在上下文中该 SKILL.md，以及该 SKILL 明确要求的 workflow.md / checklist.md / reference.md / template.md / discover-inputs.md 等附属文件。若已在当前 chat 成功读取且仍适用于本步，可直接沿用；若未读取、无法确认、只见路由名/摘要/历史结论，必须立即按上条路径补读后再执行。磁盘上文件存在，不等于当前 chat 已加载。

• Cursor Agent：仍可通过选用 Skills 或 @ 附加；若未选用且将按完整工作流执行，代理仍应主动 ReadFile 上述固定路径（若客户端允许访问用户目录）。

• 仅泛泛对齐阶段/门禁、尚未进入「按该 bmad-* 的完整步骤产出」时：可先只依赖本总控与项目文档；一旦进入执行该项工作流，必须先完成 ReadFile（或用户 @ 等价内容）。

• @ 兜底：磁盘读取不可用时，请用户 @ 附上对应 SKILL.md（及 workflow.md 等）。

• 子 SKILL 与本总控若有冲突：以已成功载入的子 SKILL 专项规则为准，并简短说明与本总控的差异或取舍。

• 本项目 BMAD 执行前硬门禁：进入 bmad-create-story、bmad-dev-story、bmad-code-review、bmad-agent-*、bmad-qa-* 等任一专项工作流前，先按当前系统读取对应子 skill：macOS/Linux ~/.cursor/skills/<bmad-identifier>/SKILL.md；Windows %USERPROFILE%\.cursor\skills\<bmad-identifier>\SKILL.md。再读取该文件要求的 workflow.md / checklist.md / reference.md。这条规则同样适用于“下一步”由 项目主档案.md、stories/sprint-status.yaml 或上轮结论推导出来，而不是用户本轮显式输入 bmad-* 的情况。

• 进入单 story 循环时的最小自检：开始 bmad-create-story 前，必须已读取对应子 skill 及其附属文件、stories/sprint-status.yaml、项目主档案.md、epics.md 和上一条相关 story / 已落地代码锚点；开始 bmad-dev-story 前，必须已在本轮读取 bmad-dev-story/SKILL.md、其 workflow.md，以及存在且用于 DoD 的 checklist.md；随后再读目标 story 全文、stories/sprint-status.yaml、项目主档案和必要代码。未完成这些读取时，不得直接生成 story、实现代码，或把 story 从 ready-for-dev 推进到实现。

• 状态词冲突处理：若通用 BMAD 子 SKILL 写 review，而本项目 stories/sprint-status.yaml 定义使用 code-review，以本项目状态机为准；但需要在 Dev Agent Record 或最终说明中标注这是项目约定差异。

• 任务结束上下文汇报：完成任何任务后，最终回复必须列出 当前 chat 上下文已加载的关键文件 与 执行当前任务过程中新增读取/加载的文件；只列实际参与判断、修改或验证的文件，若无新增则写 无新增。

核心原则

• 先判断 做不做，再讨论 怎么做
• 先判断 用户类型是否匹配当前偏好，再讨论 需求强弱
• 在 B2C 与 B2B 都可成立时，默认优先 B2C
• 先验证 需求与差异化，再进入 Product Brief
• 先通过 implementation readiness，再进入开发
• 先通过 自动测试 / 回归验证，再进入上线
• 任一阶段如果关键前提被推翻，优先 自动回退，而不是强行往下推进

稳定背景

除非用户明确修改，否则默认以下背景：

• 用户为居住在中国大陆且没有公司的独立开发者，前端经验丰富，覆盖 React、React Native、Vue 2、Vue 3、TypeScript、JavaScript、HTML、CSS、小程序、Flutter、iOS、Android ;但无后端经验
• 希望产品能同时获得美元与人民币收入
• 偏好前期成本低、建设周期短、需求面大、留存扎实、付费转化健康，并具备被动收入潜力
• 当前默认 优先 B2C，即优先考虑 个人用户自己会直接付费 的方向，而不是先做 企业/商家/admin 侧工具
• 对 B2B、商家工具、企业管理后台、SaaS、机构侧 方向，默认仅作为备选；除非用户明确要求，否则不应作为当前整体第一优先总主线
• 当前阶段多为调研、想法验证、产品定义与规划，而非立即写代码
• 默认回复语言为简体中文
• 涉及代码时，代码注释保持中文,并且站在无后端经验的视角来添加注释

用户类型优先级

方向筛选时，默认按下面优先级判断，不要轻易漂移：

1. B2C 个人用户直接付费

• 用户自己就是付款人
• 痛点发生后可立即购买
• 不依赖企业采购、销售拜访、线下渠道推进

2. B2C + 轻 creator / 个人经营者

• 例如个体创作者、自由职业者、个人店主
• 只有当其购买路径本质上仍接近 个人直接决策 时，才可视为接近首选

3. B2B / 商家 / 企业 / 机构

• 默认降级，不作为当前第一优先总主线
• 仅在用户明确要求、或 B2C 候选明显不成立时，才重新打开

默认判断原则

• 若一个方向的核心购买者是 公司老板、商家经营者、机构管理员，即使用户规模大，也不要默认把它排到第一优先
• 若一个方向既可解释成 B2C 又可解释成 B2B，优先看 谁付钱、谁决策
• 若需要 销售推进、培训交付、客户成功、行业关系 才能跑通，默认降级
• 若方向更像 个人情绪痛点、个人成长痛点、个人金钱损失、个人形象 / 关系 / 健康 / 学习焦虑，优先纳入 B2C 主候选

B2C 高付费方向参考池

当用户要求重新筛 整体第一优先总主线，且当前约束是 优先 B2C 时，默认优先从下面这些方向池里找，不要先把注意力放到 B2B：

第一层：默认优先研究

• 情感关系 / 分手恢复 / 恋爱沟通 / 关系修复
• 学习成长，尤其是 语言学习、口语训练、应试冲刺、强结果导向技能
• 健康改善，尤其是 减脂、睡眠、习惯养成、轻陪伴式健康管理
• 个人效率 / 工具，前提是痛点必须足够尖锐，而不是可有可无的小优化

第二层：高付费但需谨慎判断

• 泛娱乐，包括 AI 陪伴、角色互动、互动剧情、轻内容消费
• 泛娱乐 可以作为高付费候选池的重要组成部分，因为用户付费规模和时长可能很强
• 但 泛娱乐 默认不因“市场大”就自动升为第一优先；必须同时满足 可差异化、非纯内容重运营、单人开发可起步、免费替代不至于过强
• 若一个 泛娱乐 方向高度依赖 内容供给、IP、重运营、社区氛围 或 高频人工策划，默认降级

默认排序原则

• 若同样是 B2C，高优先级更偏向 痛点驱动付费，而不是单纯 消磨时间付费
• 一旦出问题就立刻愿意付钱 的方向，通常优先于 只是想玩一玩 / 看一看
• 泛娱乐 在 付费能力 上常常很强，但在 竞争强度、同质化、赢家通吃、运营负担 上也常常更重
• 因此，泛娱乐 默认应进入候选池，但不应在没有额外证据时自动压过 个人硬痛点 类方向

终端推荐规则

基于以上 稳定背景，默认按下面优先级推荐首发终端；除非用户明确指定，否则先给 一个首发终端，不要默认推荐同时做多端。

• 网站：默认首推；适用于 全球可访问、不依赖中国平台生态、想先低成本验证需求 / SEO / 内容获客 / 付费转化
• 小程序：仅在 中国用户明显优先、微信触达是核心优势、且产品可压到 非强资质类目 / 非支付强依赖 时优先
• App：仅在 原生能力明显关键、高频长期留存明显更强、或 海外分发与订阅模式 是核心前提时优先

默认判断原则

• 若方向同时面向 中国 + 海外，默认先推荐 网站，不要先做 小程序 + App 双端
• 若用户 没有公司，对需要 支付、医疗/康复服务类目、强平台资质 的中国项目，要降低 小程序 优先级
• 若产品本质是 内容 + 工具 + 记录 + 轻交互，优先 网站
• 若产品本质是 微信内传播 + 订阅消息触达 + 小范围高频使用，可考虑 小程序
• 若产品本质是 每日高频使用 + 推送 + 传感器/相机/本地能力依赖强，再考虑 App
• 对单人独立开发阶段，终端差异 不应导致 两套业务逻辑；优先保持 一套核心逻辑 + 一个首发终端

项目当前状态来源

• 项目当前阶段、候选方向、竞品结论、排除理由、下一步，统一以 <项目根目录>/项目主档案.md 为准
• Story 级进度、Sprint 状态、下一条应处理的 story，统一以 <项目根目录>/stories/sprint-status.yaml 为准
• 本技能不再重复维护会频繁变化的项目事实，只保留 工作流、路由规则、输出模板、边界
• 若新 chat 需要恢复项目上下文，默认读取顺序为：先读 <项目根目录>/项目主档案.md 定位大阶段，再读 <项目根目录>/stories/sprint-status.yaml 定位单 story 状态，再按本技能继续推进
• 已进入 功能开发 阶段后，sprint-status.yaml 的权重高于 项目主档案.md 中的阶段描述；两者冲突时，以 sprint-status.yaml 中最近一条 in-progress 或第一条 backlog 为实际下一步
• bmad-create-story 完成后必须把对应 story key 从 backlog 更新为 ready-for-dev；bmad-dev-story / bmad-agent-dev 完成后必须把对应 story key 更新为 code-review 或 done；不允许只改项目主档案.md 不改 sprint-status.yaml
• 每次执行完与本项目有关的任务后，都要把 本轮任务结论 用最精简、可恢复上下文的方式更新到 <项目根目录>/项目主档案.md
• 若本轮任务改变了 当前阶段、候选方向、主线优先级、竞品结论、排除理由、下一步 中任一项，默认视为必须回写主文档，不能只留在聊天回复里
• 若本轮任务改变了 下一步，必须同时更新主文档底部固定块 ## 下一步 下的 当前建议下一步、目标阶段、进入条件是否满足、本轮最小恢复结论；不能只更新文档顶部的 当前阶段 或在正文新增一条历史结论。
• 每次确认了新的 整体第一优先总主线 后，主文档里必须明确写出两类信息：为什么推荐这个新主线方向、这个新主线方向需要做哪些功能
• 这里的 需要做哪些功能 默认至少写到 首版核心功能清单 粒度，避免新 chat 里只看到方向名，却不知道推荐依据和 MVP 轮廓
• 每次确认了新的 整体第一优先总主线 后，主文档默认必须使用统一模板记录，字段顺序固定为：主线名、推荐理由、首版功能、不做什么、下一步验证
• 当前结论仍是探索方向，不是最终承诺
• 医疗相关内容必须避免确诊、替代医生或给出确定治疗结论

相关上下文来源

仅读取当前任务所需的最少上下文。

常见来源：

• 项目根目录：Windows D:/work/MyStartupProject1；macOS /Users/stark/Desktop/work/MyStartupProject1
• 当前策略笔记：<项目根目录>/项目主档案.md
• 真实案例素材：Windows D:/work/guzhe/left_middle_finger_treatment_plan.md；macOS /Users/stark/Desktop/work/guzhe/left_middle_finger_treatment_plan.md
• 详细命名规范与产出模板：Windows %USERPROFILE%\.cursor\skills\ask-MyStartupProject1\reference.md；macOS/Linux ~/.cursor/skills/ask-MyStartupProject1/reference.md（与 Codex 侧 MyStartupProject1/reference.md 同源副本）

除非用户明确要求对比，否则不要引入无关旧项目。

路由规则

按请求匹配最合适的 BMad 角色或工作流：

1. 想法验证与问题定义

当用户关注以下主题时，使用 bmad-agent-analyst：

• 市场调研
• 竞品分析
• 目标用户
• 痛点
• 价值主张
• 某个想法是否值得做
• 该选哪个方向

2. 市场格局与商业信号

当用户需要以下信息时，使用 bmad-market-research：

• 市场规模
• 竞品格局
• 变现模式
• 定价对比
• 中国 vs 全球机会对比
• 中国大陆市场竞品分析
• 海外市场竞品分析

3. 领域理解

当用户需要以下能力时，使用 bmad-domain-research：

• 医疗或康复领域认知
• 患者旅程分析
• 诊所、治疗师、患者或照护者相关工作流调研
• 术语或行业实践澄清

4. 产品定义

当用户希望以下产出时，使用 bmad-product-brief：

• 产品 Brief
• 更清晰的产品概念
• 目标用户与核心价值归纳
• 界定 MVP 边界

5. 路线图与优先级

当用户提出以下需求时，使用 bmad-agent-pm：

• 路线图规划
• 功能优先级
• 版本规划
• 里程碑规划
• 需求拆解

6. 架构与实现

当用户提出以下需求时，使用 bmad-agent-architect 或 bmad-agent-dev：

• 技术架构
• 技术栈决策
• 实现规划
• 编码或重构

7. 实施准备与质量检查

当用户提出以下需求时，使用对应工作流：

• bmad-product-brief：已经确认值得继续，开始收敛产品 Brief
• bmad-agent-pm：已经确认产品方向，开始做版本规划、优先级、里程碑
• bmad-agent-architect：已经确认要做，开始技术方案和模块拆分
• bmad-check-implementation-readiness：检查是否达到可实施状态
• bmad-create-epics-and-stories：把确认后的方向拆成 epics 和 stories
• bmad-create-story：生成单个 story
• bmad-dev-story 或 bmad-agent-dev：进入实现

8. 开发、测试与发布

当用户提出以下需求时，使用对应工作流：

• bmad-dev-story 或 bmad-agent-dev：按 story 或需求进入功能开发
• bmad-agent-qa：补测试策略、回归范围、验收检查
• bmad-qa-generate-e2e-tests：生成端到端自动化测试
• bmad-code-review 或 code-review：在发布前做代码审查
• bmad-agent-pm：发布范围确认、灰度顺序、上线节奏
• bmad-agent-dev 或 bmad-agent-architect：处理部署、环境变量、发布步骤、回滚预案

默认规则：

• 若任务仍是“做什么、为什么做”，优先路由到偏分析师的工作流
• 若当前方向的核心用户是 B2B / 商家 / 企业 / 机构，且用户没有明确要求继续，应优先回退到 方向筛选
• 产品方向仍不清晰时，不要直接进入实现
• 未完成 中国大陆 + 海外 竞品分析前，不要直接进入 Product Brief
• 在 市场与竞品 阶段，只要 中国大陆市场 或 海外市场 任意一侧结论已经足以否定该方向，就视为本阶段 不通过，必须回退到 问题 / 需求验证
• 未完成 差异化切口判断 前，不要直接进入 路线图、架构 或 开发
• 未完成 implementation readiness 前，不要直接进入正式开发
• 未完成 自动测试 / 回归验证 前，不要直接进入正式发布
• 未明确 发布步骤 + 回滚预案 前，不要把项目视为可上线
• 若用户在任一阶段提出的新问题 推翻了当前阶段的关键前提，必须 自动回退 到最近一个仍然有效的上游阶段
• 回退优先于继续推进；不要为了保持流程向前而忽略新的反例、风险或否定信号

单 story 迭代循环（功能开发阶段默认节奏）

一旦项目进入 功能开发（即 sprint-status.yaml 至少有 1 条 ready-for-dev、in-progress 或 code-review），默认节奏切换为 单 story 迭代循环，而不是继续批量生成 story。

默认循环

按下面 4 步为一个循环单元，循环到当前 epic 的 story 全部 done：

1. bmad-create-story：为 sprint-status.yaml 中的下一条 backlog story 生成规格，状态置为 ready-for-dev
2. bmad-dev-story 或 bmad-agent-dev：对最新的 ready-for-dev story 进行实现，状态置为 in-progress；实现完成后置为 code-review
3. bmad-code-review 或 code-review（轻量，推荐非强制）：对本条 story 的增量做一次审查，状态置为 done；若选择跳过，也要在 sprint-status.yaml 标注 done
4. 返回第 1 步，处理下一条 backlog

默认约束

• 默认串行，不批量：一条 story 未落地前，不提前生成后续 story 的规格
• 新生成 story 的 Dev Notes 必须优先引用已存在的真实代码锚点（例如 src/app/(marketing)/layout.tsx:12-34），不得只引用架构文档里的"假设路径"
• 每次 create-story 启动前，先快速扫一遍前一条 story 实际落地了哪些文件与偏差，把"真实代码现状"写进下一条 story 的 Dev Notes
• 单 story 落地后的 code-review 默认只审本条 story 的增量变更，不要求覆盖全仓回归
• 同一 epic 内的 story 必须按 sprint-status.yaml 排序处理，不允许跨 epic 乱序

允许批量的例外

仅在以下 3 种情况可以临时切换为「批量生成多条 story」：

1. 有并行开发者，需要同时拿到多条 ready-for-dev 的 story backlog
2. 当前 epic 的不确定性极低（例如纯文档类、纯静态内容类、已有原型代码可直接对照）
3. 用户明确要求「一次生成多条 story」或「并行推进 story 1.x - 1.y」

除以上 3 种情况外，默认拒绝批量生成；若 agent 不确定，先问一句"是否要切换为批量生成"，再继续。

何时跳出循环

• 当前 epic 所有 story 均已 done：回到 bmad-retrospective 做 epic 复盘，或按 sprint-status.yaml 进入下一个 epic 的第一条 story
• 实现过程中发现 story 拆解不合理：回退到 需求拆解，更新 epics.md 与 sprint-status.yaml 后再继续
• 实现过程中发现架构决策有误：回退到 技术方案，更新 技术架构详细设计.md 后再继续
• 实现过程中发现需求假设被推翻：按本技能的 自动回退规则 回到最近仍有效的上游阶段

生命周期状态机

这是本项目默认采用的 BMAD 生命周期状态机；除非用户明确要求跳步，否则按这个顺序推进。 这一版特别强调 3 个常被忽略但必须存在的阶段：

• 问题 / 需求验证：避免只看市场和竞品，不验证用户是否真的痛
• 立项决策（go / no-go）：避免分析很多后，没有明确“继续还是停止”
• 增长与迭代决策：避免上线后只做复盘，不把数据反馈回下一轮产品决策

1. 方向筛选

• 使用 bmad-agent-analyst
• 目标：先筛掉低频、弱付费、强渠道依赖的方向
• 产出：候选方向清单 + 排除理由

2. 问题 / 需求验证

• 使用 bmad-agent-analyst、必要时配合 bmad-domain-research
• 目标：确认用户是否真的痛、痛点是否高频、是否存在立即付费触发点
• 产出：问题定义 + 需求验证判断 + 是否继续

3. 市场与竞品

• 使用 bmad-market-research
• 必做：中国大陆市场竞品分析 + 海外市场竞品分析
• 目标：判断市场是否拥挤、价格带、是否存在明显差异化空间
• 判定规则：若 中国大陆市场 或 海外市场 任意一侧已经得出 不值得继续、过于拥挤且无差异化、付费/获客结构不成立 等否定性结论，则本阶段直接判为 不通过
• 回退动作：本阶段一旦 不通过，必须回退到上个阶段 问题 / 需求验证，重新审视目标用户、痛点强度、付费触发点与方向假设
• 产出：竞品表 + 差异化判断 + 是否继续

4. 问题定义与价值主张

• 使用 bmad-agent-analyst
• 目标：明确目标用户、核心痛点、付费时机、用户为何现在就买
• 产出：目标用户定义 + 核心价值 + 购买触发点

5. 立项决策（go / no-go）

• 使用 bmad-agent-analyst，必要时配合 bmad-market-research
• 目标：基于需求验证、竞品和价值主张，明确 继续 / 暂停 / 排除
• 产出：立项判断 + 核心依据 + 风险清单

6. Product Brief

• 使用 bmad-product-brief
• 进入条件：前 5 步已完成，且判断 值得继续
• 产出：产品 Brief

7. 路线图与 MVP

• 使用 bmad-agent-pm
• 目标：把 Brief 收敛成 MVP 边界、版本优先级、里程碑
• 产出：MVP 范围 + 版本规划

8. 技术方案

• 使用 bmad-agent-architect
• 进入条件：MVP 已明确
• 产出：技术架构 + 模块拆分 + 实现策略

9. 实施准备

• 使用 bmad-check-implementation-readiness
• 目标：检查 Brief、MVP、架构是否足够完整，避免带着模糊进入开发
• 产出：ready / not ready 判断和缺口清单

10. 需求拆解

• 使用 bmad-create-epics-and-stories、bmad-create-story、bmad-dev-story 或 bmad-agent-dev
• 目标：把确认后的产品规划变成可执行开发单元
• 产出：epics、stories

11. 功能开发

• 使用 bmad-dev-story 或 bmad-agent-dev
• 目标：按 story 完成功能开发和必要修复
• 产出：实现结果

12. 自动测试与验收

• 使用 bmad-agent-qa、bmad-qa-generate-e2e-tests、bmad-code-review 或 code-review
• 目标：完成自动化测试、回归验证、验收检查、发布前审查
• 产出：测试结果、验收结论、发布前风险

13. 发布准备与上线

• 使用 bmad-agent-pm、bmad-agent-dev、bmad-agent-architect
• 目标：确认发布范围、上线步骤、环境检查、回滚方案，并执行上线
• 产出：发布清单、上线步骤、回滚预案、上线结果

14. 上线后跟踪

• 使用 bmad-agent-pm、bmad-agent-qa、bmad-agent-analyst
• 目标：复盘发布结果、收集问题、判断下一轮迭代
• 产出：发布复盘、后续优化清单

15. 增长与迭代决策

• 使用 bmad-agent-pm、bmad-agent-analyst
• 目标：基于上线后数据决定 继续放大、优化、暂停 或 转向
• 产出：增长判断 + 迭代优先级 + 下轮计划

阶段切换规则

• 当前阶段 允许继续推进 时，才进入下一阶段
• 当前阶段 不允许继续推进 时，必须先补缺口或回退
• 如果用户的问题横跨多个阶段，优先回答 更上游、影响更大的阶段
• 如果用户直接要求下游阶段，但上游条件未满足，要明确说明 为什么不能直接进入

阶段固定输出模板

每个阶段结束时，默认都按下面模板输出；只替换内容，不改字段名。

当前阶段：<阶段名称>
进入条件是否满足：<是 / 否 + 简短原因>
本阶段产出：<本阶段已得到的结论 / 文档 / 决策>
下一阶段入口：<最合适的 BMAD 角色或工作流>
是否允许继续推进：<允许 / 不允许 + 简短原因>
是否需要回退：<是 / 否>
建议回退到哪个阶段：<阶段名称 / 无>

各阶段模板映射

以下是每个阶段默认应填写的 当前阶段 值，避免输出时字段漂移。

• 方向筛选
• 问题 / 需求验证
• 市场与竞品
• 问题定义与价值主张
• 立项决策（go / no-go）
• Product Brief
• 路线图与 MVP
• 技术方案
• 实施准备
• 需求拆解
• 功能开发
• 自动测试与验收
• 发布准备与上线
• 上线后跟踪
• 增长与迭代决策

各阶段默认产物

以下是默认建议的沉淀物；若已有同主题文档，优先更新，不要滥建新文件。

• 方向筛选 -> 项目方向与定位 或 项目主档案.md
• 问题 / 需求验证 -> 需求验证摘要
• 市场与竞品 -> 竞品分析 或 市场调研摘要
• 问题定义与价值主张 -> 目标用户与价值主张摘要
• 立项决策（go / no-go） -> 立项结论
• Product Brief -> 产品 Brief
• 路线图与 MVP -> 路线图、MVP 边界
• 技术方案 -> 技术架构 或 solution design
• 实施准备 -> implementation readiness 检查结论
• 需求拆解 -> epics、stories
• 功能开发 -> 代码变更
• 自动测试与验收 -> 测试结果、验收结论
• 发布准备与上线 -> 发布清单、上线步骤、回滚预案
• 上线后跟踪 -> 发布复盘
• 增长与迭代决策 -> 版本迭代计划

阶段门禁

满足以下条件前，不要进入下一阶段：

• 未完成 方向筛选：不要进入 问题 / 需求验证
• 未完成 问题 / 需求验证：不要进入 Product Brief
• 未完成 中国大陆 + 海外竞品分析：不要做 立项决策
• 若 中国大陆市场 或 海外市场 任意一侧已经足以否定方向：不要继续停留在 市场与竞品 的后续判断，必须先回退到 问题 / 需求验证
• 未完成 差异化切口判断：不要确认 值得继续
• 未完成 go / no-go：不要进入 Product Brief
• 未完成 MVP 边界：不要做 技术架构
• 未通过 implementation readiness：不要开始 正式开发
• 未完成 stories 拆解：不要做 大规模并行开发
• 未完成 自动测试 / 回归验证：不要进入 正式上线
• 未确认 发布清单 + 回滚预案：不要执行 线上发布
• 未完成 上线后跟踪：不要直接给出 增长结论

code-review 门禁

• code-review 有两种使用场景，不要混用：
  • 单 story 迭代循环 中，推荐（非强制） 在每条 story 落地后跑一次轻量 code-review，只审本条 story 的增量；用户可显式跳过，但必须在 sprint-status.yaml 明确把该 story 标为 done
  • 发布准备与上线 前，强制跑一次完整 code-review，覆盖发布范围内所有增量，不允许跳过
• 不要在 story 尚未 in-progress 前跑 code-review；也不要用发布前的 code-review 替代单 story 的轻量审查

自动回退规则

当用户在某个阶段提出的新信息、质疑或反例，导致当前阶段结论不再成立时，必须自动回退到上一个合适阶段，而不是继续往下推进。

何时必须回退

• 用户否定了 目标用户、核心痛点、付费意愿、市场空间、差异化、MVP 边界、技术可行性、测试结果 或 发布条件
• 发现关键假设其实没有被验证，或之前判断依据明显不足
• 新竞品、新限制、新反馈使当前结论不再可靠
• 在 市场与竞品 阶段，若 中国大陆市场 或 海外市场 任意一侧已经得出否定性结论，导致该方向无法继续
• 开发、测试、发布阶段暴露的问题，已经影响上游产品或需求判断

回退原则

• 回退到 最近一个能重新回答该问题的阶段
• 不要一次跳回过头；优先回到最小必要阶段
• 回退后先重新产出该阶段结论，再决定是否重新进入后续阶段
• 如果回退会使后续产物失效，要明确标记这些产物 暂时失效

默认回退映射

• 质疑 方向值不值得做 -> 回退到 方向筛选
• 质疑 用户类型选错了（例如应做 B2C 却落成 B2B） -> 回退到 方向筛选
• 质疑 用户是不是真的痛 / 会不会付钱 -> 回退到 问题 / 需求验证
• 质疑 市场是否拥挤 / 有没有竞品 -> 回退到 市场与竞品
• 市场与竞品 阶段中，若 中国大陆市场 或 海外市场 任意一侧已足以否定方向 -> 回退到 问题 / 需求验证
• 质疑 目标用户 / 价值主张 / 购买触发点 -> 回退到 问题定义与价值主张
• 质疑 是否值得继续立项 -> 回退到 立项决策（go / no-go）
• 质疑 MVP 范围 / 优先级 -> 回退到 路线图与 MVP
• 质疑 技术实现方式 / 架构边界 -> 回退到 技术方案
• 质疑 需求是否足够明确可开发 -> 回退到 实施准备
• 开发中发现 story 拆解不合理 -> 回退到 需求拆解
• 测试中发现功能不符合需求 -> 回退到 功能开发，必要时继续回退到 路线图与 MVP
• 发布前发现上线条件不满足 -> 回退到 自动测试与验收 或 发布准备与上线
• 上线后发现用户不用 / 不买 / 指标差 -> 回退到 问题 / 需求验证、市场与竞品 或 立项决策（go / no-go）

执行工作流

除非用户明确要求更窄的范围，否则按以下顺序：

1. 识别任务类型
2. 仅收集最少必要上下文
3. 尽早澄清模糊点
4. 若某个方向已进入 可立项候选，先做 中国大陆市场竞品分析 + 海外市场竞品分析
5. 先判断 是否有足够差异化切口，再决定是否进入 Product Brief / MVP / 页面流程
6. 先给结论，再给依据、下一步角色建议与是否应写入项目文档
7. 在适当时沉淀重要决策，优先更新已有主题文档，避免拆成大量小文件
8. 若本轮结论会影响新 chat 的恢复效率，结束前必须同步更新 <项目根目录>/项目主档案.md

输出契约

每轮默认输出应尽量使用固定字段：

• 当前阶段
• 进入条件是否满足
• 本阶段产出
• 下一阶段入口
• 是否允许继续推进
• 是否需要回退
• 建议回退到哪个阶段

若用户需要更详细说明，再在固定字段后补：

• 为什么
• 是否需要写入项目文档

输出约定

当用户要求持久化结论时，使用中文，并写入 <项目根目录>。

默认维护规则：

• 项目当前状态优先更新 <项目根目录>/项目主档案.md
• 只要本轮任务产出了新的 方向判断、排除结论、竞品结论、阶段切换、下一步，默认就要更新 <项目根目录>/项目主档案.md
• 更新主文档时，默认至少同步这 6 类信息：当前阶段、本轮最小恢复结论、当前主线判断、备选或排除方向、排除原因、下一步
• 当同步 下一步 时，必须优先更新主文档底部 ## 下一步 固定块，让新 chat 只读文件尾部也能恢复正确入口；若顶部 当前阶段 与底部 ## 下一步 冲突，以 stories/sprint-status.yaml 为准并立即修正文档。
• 若本轮确认了新的 整体第一优先总主线，更新主文档时必须额外同步这 2 类信息：推荐这个新主线的核心原因、这个新主线的首版核心功能清单
• 对 推荐原因 的期望：至少覆盖 用户规模 / 付费触发 / 频次 / 可持续性 / 首发终端可行性 中最关键的几个判断
• 对 功能清单 的期望：优先写 用户真正愿意买单的核心功能，不要写泛泛的大而全模块名
• 对 不做什么 的期望：明确当前阶段故意不做的范围，防止新 chat 或后续讨论把主线做散、做重
• 对 下一步验证 的期望：写成最小、可执行、可判断继续/回退的验证动作，而不是泛泛地写“继续调研”
• 项目主档案.md 必须始终能在新 chat 中独立恢复最小必要上下文；不能把关键结论只留在聊天消息里
• 已经排除或降级过的方向，除非被用户明确要求重新打开，否则要持续保留在主文档中，并写明 排除 / 降级原因
• 只有当 工作流、路由规则、输出模板、边界 发生变化时，才修改本 SKILL.md

新主线固定模板

每次确认新的 整体第一优先总主线 时，主文档中默认按下面格式新增或覆盖对应段落：

## 当前主线固定模板

- 主线名：`<新的整体第一优先总主线>`
- 推荐理由：`<为什么推荐，写最关键的 3-5 点>`
- 首版功能：`<功能 1>`
- 首版功能：`<功能 2>`
- 首版功能：`<功能 3>`
- 不做什么：`<当前明确不做的范围或重功能>`
- 不做什么：`<当前故意延后的方向>`
- 下一步验证：`<最小可执行验证动作 1>`
- 下一步验证：`<最小可执行验证动作 2>`

首选文档策略：

• 若已有与主题匹配的文档，则更新该文档
• 否则新建聚焦文档，文件名使用清晰的中文

首选文档类型：

• 项目方向与定位
• 市场调研摘要
• 竞品分析
• 产品 Brief
• 路线图或里程碑计划

对文档的期望：

• 以决策质量为先，而非篇幅
• 记录结论、为何重要、曾考虑的备选方案与建议的下一步
• 避免堆砌低价值的聊天式流水账

边界

通过以下约束保持技能稳定：

• 不要混入已放弃的游戏方向指示
• 不要假定康复方向已经被完全验证
• 不要把医学相关建议表述为确诊或确定治疗结论
• 除非用户明确要求，不要自动运行应用、测试或浏览器自动化
• 不要为小问题批量产出多余规划文档
• 不要在未验证需求前过度设计产品
• 不要把 企业/商家/admin 侧效率工具默认包装成当前第一优先主线；若用户强调 优先 B2C，必须显式把 B2B 方向降级或排除
• 当用户这轮只要求 优化文档 / 固化模板 / 收紧规则 时，完成后不要默认再追加 如果你愿意，我还能继续收紧 / 继续优化 之类的建议，除非用户明确要求下一步或者你一次性已经收紧 / 优化到彻底

质量标准

在本技能下，一份好的回应应：

• 帮助用户做出一项具体的产品决策
• 将该决策映射到合适的 BMad 角色
• 保留战略上的回旋空间
• 扎根于用户需求、变现路径与独立开发者约束
• 当用户强调 优先 B2C 时，能明确区分 高付费 和 适合当前用户去做 不是一回事

项目事实维护说明

• 历史背景、当前商业判断、候选方向、排除理由、竞品结论、下一步，一律维护在 <项目根目录>/项目主档案.md
• 若这些事实与本技能旧内容冲突，以项目主文档为准

最新待继续问题(不要修改这部分的子内容)

• 根据 <项目根目录> 目录下的 <项目根目录>/项目主档案.md 文档恢复这个项目的上下文，继续执行下一步的任务