utility-pm-workflow-builder

PM 工作流构建器

此技能用于为 pm-skills 库创建新的多技能工作流。 它会在暂存区生成一份工作流实施包，包含草稿 _workflows/<name>.md 文件、草稿 commands/workflow-<name>.md 命令，以及跨领域 更新检查清单，供审核后再移至规范位置。构建器负责编写，不会执行技能链， 也不会将自己的输出移至规范位置。

适用场景

• 你有创建新多技能工作流的想法（“我需要一个用于季度业务回顾的工作流”）
• 你知道想串联哪些技能，并希望将其持久记录下来（“串联 competitive-analysis、experiment-results、pivot-decision”）
• 一次 /chain 运行（编排器 Mode B）证明该流程可复用，且其完成输出建议将该技能链提升为持久工作流；此时将建议中的完整技能链表达式交给此技能

不适用场景

• 只想运行一次流程，不需要编写任何内容 -> 使用 /chain 命令或直接使用 utility-pm-workflow-orchestrator
• 要构建或修改单个技能 -> 使用 utility-pm-skill-builder、 utility-pm-skill-validate 或 utility-pm-skill-iterate
• 要自定义现有工作流 -> 直接编辑其 _workflows/<name>.md；如果覆盖度较高， 下方的重叠分析会建议你这样做

说明

第 1 步：理解想法

接受以下三种形式的任何一种输入，后续流程都相同：

• 问题优先：“我需要一个用于 X 的工作流。”确定反复出现的 PM 流程、执行者，以及该流程应留下的产物记录。
• **技能优先：**用户已经想要串联的技能列表。
• **技能链提升：**完整的技能链表达式（例如 measure-experiment-results -> discover-stakeholder-summary），通常 复制自编排器的完成建议，并附上该次运行所用的上下文。

如果想法不够明确，只提出一个澄清问题（反复出现的触发条件和最终产物）， 然后继续。不要连续追问。

第 2 步：重叠分析 + 必要性门槛

运行时扫描 _workflows/ 目录，获取当前清单 （列出除 README.md 以外的所有 *.md）。切勿依赖记忆中的数量 或硬编码清单。将想法与所有现有工作流进行比较：

• 列出所有重叠的工作流及其覆盖内容。
• 如实估算覆盖重叠程度。

**终止门槛（覆盖重叠度 >70%）：**按以下顺序提出建议：(a) 自定义现有工作流；(b) 为其添加一个步骤；或 (c) 仅在偶尔运行时 使用 /chain。不要继续。

**必要性门槛（存在任何有意义的重叠时）：**要求提供 2–3 个具体场景， 说明现有工作流为何无法产出所需内容。没有这些证据或用户明确豁免时， 不得通过此门槛（将豁免记录在工作流实施包的 Decision 部分）。

步骤 3：设计步骤顺序

与用户一起选择并排列步骤。在编写时应用链式表达式 契约的验证规则 （skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md， Mode B Chain Expression Contract）：

• 每个步骤都必须按精确名称解析到已安装的技能 skills/<name>/SKILL.md。 切勿近似匹配或自动更正；若未匹配，则拒绝该步骤，并提供最接近的真实名称 （仅作建议，绝不替换）。
• 仅限 Category 1 内容技能。 拒绝将以下内容用作步骤，并各用一句话说明原因：Tier-3 维护技能（utility-pm-skill-*、 utility-pm-release-conductor、utility-pm-changelog-curator、 utility-update-pm-skills、foundation-prioritized-action-plan），会分派给子 Agent 的调度技能（utility-pm-critic、 utility-pm-workflow-orchestrator 及同类技能），以及现有工作流（工作流不能嵌套工作流）。此构建器本身属于 Tier-3，因此在设计上不可能引用自身。
• 对于每个步骤，编写交接说明：说明该步骤会从上一步的输出中获取什么，以及必须为下一步产出什么。正是这些编写好的交接指引，让工作流经久耐用，而非临时拼凑的链条；没有实际交接内容的方案尚未准备就绪。

步骤 4：生成方案包

将完整的 Workflow Implementation Packet 写入 _staging/workflows/<name>/（已在 gitignore 中；采用与技能构建器相同的审查模型）。绝不要写入规范位置。

_staging/workflows/<name>/
├── workflow.md      <- draft _workflows/<name>.md
├── command.md       <- draft commands/workflow-<name>.md
└── PACKET.md        <- decision, overlap analysis, checklist, promotion steps

使用 references/TEMPLATE.md 作为方案包格式。工作流草案必须包含当前 _workflows/*.md 文件共有的完整章节清单（参见 TEMPLATE 内嵌的骨架）；命令草案应仿照现有的 commands/workflow-*.md 格式，其中每个步骤都包含一个字面上的 skills/<name>/SKILL.md 路径，并以 $ARGUMENTS 页脚结尾。根据最终步骤顺序生成线性 mermaid 上下文流图（步骤名称作为节点，执行顺序作为边）。

步骤 5：审查与晋升指引

展示方案包，然后停止。构建器本身绝不执行晋升。获批后，由用户（或后续会话）将草案移至规范路径，并完成方案包的 Cross-Cutting Checklist；该清单列出添加工作流会触及的所有计数项和文档位置，包括验证器无法检测的 .github/workflows/release.yml 发布说明模板。构建器绝不自行编辑这些跨领域文件。

输出格式

方案包遵循 references/TEMPLATE.md：

1. Decision——建议及 Why Gate 证据（或记录的例外批准）
2. Overlap Analysis——每个重叠工作流、其涵盖内容及差距
3. Workflow Draft——完整的 _workflows/<name>.md 内容
4. Command Draft——完整的 commands/workflow-<name>.md 内容
5. Cross-Cutting Checklist——晋升时需要更新的每个位置及其强制执行的验证器（如果不存在验证器，则标注为“validator-blind”）
6. Promotion Steps——移动、验证和校验的顺序

参见 references/EXAMPLE.md，其中包含一份完整的示例方案包。

质量检查清单

提交工作包之前，请确认：

• 重叠分析已扫描当前的 _workflows/ 目录（没有使用记忆中的列表，也没有硬编码数量）
• Why Gate 的证据具体（列出命名场景），或已明确记录例外
• 每个步骤都能通过完全一致的名称匹配到已安装的技能
• 步骤中没有 Tier-3 维护技能、分发技能或工作流
• 每个步骤都有编写好的交接说明（说明消耗项 / 产出项），而不只是技能名称
• 工作流草稿包含 TEMPLATE 骨架中的所有章节（元数据表、包含 Do NOT use 的 When to Use、各步骤内容块、上下文流向图、提示、质量检查清单、另请参阅）
• 命令草稿列出每个步骤对应的 skills/<name>/SKILL.md 路径，并以 $ARGUMENTS 页脚结尾
• mermaid 图与最终步骤顺序完全一致
• 所有内容均写在 _staging/workflows/<name>/ 下；未触碰任何规范路径
• 完整复现 Cross-Cutting Checklist，包括 .github/workflows/release.yml 发布说明行

参考文件

• 工作包模板：references/TEMPLATE.md
• 完整示例（季度业务评审）：references/EXAMPLE.md
• 编写时应用的链式表达式约定：skills/utility-pm-workflow-orchestrator/references/PARSE-CONTRACT.md
• 工作流示例：_workflows/sprint-planning.md、_workflows/customer-discovery.md
• 命令示例：commands/workflow-sprint-planning.md
• 单技能构建器的同级工具：skills/utility-pm-skill-builder/SKILL.md