pm-workflow

name	pm-workflow
description	全流程产品设计向导，负责迭代生命周期管理并按需调度子技能。当用户提出一个产品想法或需求，需要从零开始经历完整的“调研 -> 设计 -> 原型 -> PRD”端到端工作流，或需要管理/追踪项目迭代版本时，必须作为入口主控技能优先触发。

PM Workflow 技能 (产品工作流主控)

你必须使用此技能引导用户完成端到端的产品设计全流程。它作为主控节点（Orchestrator），负责迭代生命周期管理和子技能的强制调度流转。

⚠️ 核心红线规则 (CRITICAL RULES)

在执行任何工作流之前，你必须深刻理解并严格遵守以下规则：

1. 严格确认与阶段门禁 (CRITICAL SYSTEM OVERRIDE)：为了克服底层模型“试图一次性完成所有步骤”的坏习惯，在标准工作流的每个阶段结束时，你必须展示所有生成的文件链接并请求用户确认。你必须在此处结束你的回复（停止生成），把控制权交还给用户。绝对禁止自作主张假设用户已同意并自动进入下一个阶段。
2. 强制握手与移交 (Handshake Protocol)：当从一个阶段流转到下一个阶段时，你必须立刻中断当前的主控思考，直接将上下文移交给对应的子技能执行（例如：[pm-kickoff], [pm-design]）。不要尝试使用通用能力去手动执行阶段任务。
3. 强制顺序执行：除非在阶段 0 中触发了“快速通道”，否则你绝对不能跳过任何工作流阶段。
4. 强制收尾追踪：当用户表示 PRD 已完成或需求“结束”时，你必须执行“阶段 5 (迭代收尾)”。你绝对不能默默结束对话而不去更新项目的追踪日志。

执行工作流 (Execution Workflow)

0. 阶段 0: 初始化与路由分发 (主控逻辑)

• 动作 1 (目录与环境初始化)：检查是否存在 docs/prd/ 目录。如果不存在（全新项目），你必须主动创建该基础目录结构，并初始化全局日志文件 docs/prd/ITERATION_LOG.md。所有迭代文件夹必须统一创建在 docs/prd/ 目录下（格式为 docs/prd/YYMM_N）。如果你在项目根目录发现了遗留的旧 YYMM_N 结构，你必须向用户确认是否将其一键迁移至 docs/prd/ 目录下，并连同 ITERATION_LOG.md 一起迁移。
• 动作 2 (读取迭代历史)：尝试读取 docs/prd/ITERATION_LOG.md。如果文件不存在（或为空），你必须先初始化创建该文件，并在此时告知用户当前无历史迭代记录；如果文件存在且有记录，则向用户展示最近的 3 个迭代记录。
• 动作 3 (强制确认门禁)：
  • 如果是无历史记录的全新项目，询问用户：“当前为全新项目，是否创建新的迭代（例如 YYMM_1）？”
  • 如果有历史记录，询问用户：“请选择是追加到现有迭代，还是创建一个新的迭代？”
  • 等待用户回复确认。用户确认并选择后，你必须根据选择创建对应的新迭代目录（如 docs/prd/YYMM_1）和该迭代的 Requirement_List.md，或者继续沿用用户选择的已有迭代目录。
• 动作 4 (路由分发)：根据用户的输入内容进行判定：
  • 如果用户仅提供了一句话/简短描述，默认走 [标准工作流]。
  • 如果用户提供了一批已有的原型文件或批量需求，你必须询问用户走 [标准工作流] 还是 [快速通道]。
• 动作 5 (生成需求目录并登记)：在确定了迭代目录（docs/prd/YYMM_N）和工作流分支后，扫描提取当前最大需求 ID（例如 F3）：
  • 目录命名规范：生成的需求文件夹名称必须包含用户初始需求的核心词汇，格式为 需求ID_需求名称（例如 F3_用户登录 或 F4_支付收银台）。
  • 生成与登记：
    • 如果走 [标准工作流]：生成单个新的需求文件夹。同时，你必须立即在 docs/prd/ITERATION_LOG.md 和当前迭代的 Requirement_List.md 中创建对应的初始记录。
    • 如果走 [快速通道]：根据用户提供的批量文件或需求，一次性生成对应数量的一批需求文件夹。同时，你必须立即在日志和需求清单中为这一批需求创建对应的初始记录。
• 动作 6 (快速通道执行协议)：如果确定走 [快速通道]，你必须跳过阶段 1~3，直接将上下文移交给 [pm-prd] 技能在各目录下生成 Markdown PRD。产出后直接进入阶段 5 收尾，并且绝对不需要询问或创建交互式 PRD（完全跳过阶段 6）。

1. 阶段 1: 需求启动 (Kickoff & Requirements)

• 动作 1 (强制移交)：你必须将上下文移交给 [pm-kickoff] 技能执行需求分析。
• 动作 2 (阶段门禁)：当 [pm-kickoff] 产出背景文档后，向用户展示链接并提问确认。强制停止当前回合，等待批准！

2. 阶段 2: 架构与设计 (Design & Architecture)

• 动作 1 (强制移交)：你必须将上下文移交给 [pm-design] 技能执行系统设计。
• 动作 2 (阶段门禁)：当 [pm-design] 产出流程图与页面结构后，向用户展示链接并提问确认。强制停止当前回合，等待批准！

3. 阶段 3: 原型制作 (Prototyping)

• 动作 1 (强制移交)：你必须将上下文移交给 [pm-prototype] 技能执行原型生成与一致性审计。
• 动作 2 (阶段门禁)：等待用户在浏览器中验证完 HTML 文件并由该技能完成逆向同步。询问：“原型已验证且同步。是否生成最终的 PRD？”强制停止当前回合，等待批准！

4. 阶段 4: 文档生成 (Documentation)

• 动作 1 (强制移交)：你必须将上下文移交给 [pm-prd] 技能执行 Markdown PRD 编写。
• 动作 2 (阶段门禁)：当 [pm-prd] 产出文档后，询问：“PRD 已确认。准备好结束本次迭代并更新日志了吗？”强制停止当前回合，等待批准！

5. 阶段 5: 迭代收尾 (Iteration Wrap-up)

• 动作 1 (读取规范)：你必须读取参考文件 [references/Log_Format.md](references/Log_Format.md)。
• 动作 2 (更新全局日志)：由于在阶段 0 已经创建了基础记录，严格按照上述参考规范，更新 docs/prd/ITERATION_LOG.md 的对应状态。
• 动作 3 (更新迭代清单)：严格按照上述参考规范，更新 docs/prd/YYMM_N/Requirement_List.md，追加最终的 PRD 链接并标记完成。
• 动作 4 (可选转化确认)：
  • 如果当前是 [标准工作流]：祝贺用户完成迭代，并明确询问：“您是否需要生成带左侧目录与动态联动效果的 HTML 交互式 PRD？(如果需要，我将移交给 [interactive-prd-builder] 技能处理)”。
  • 如果当前是 [快速通道]：祝贺用户完成迭代，直接结束本回合。绝对不要询问或触发 [interactive-prd-builder]。

6. 阶段 6: 交互式 PRD (可选扩展)

• 条件与动作：仅当用户在阶段 5 结束时回答“是/需要”时，你必须将上下文移交给 [interactive-prd-builder] 技能。