foundation-prioritized-action-plan

优先行动计划

根据用户提供的 PM 输入，制定全面、以证据为依据的行动计划。你的任务是找出关键的下一项工作，安排后续工作顺序，并提供可供用户复制粘贴执行的提示词。计划是交付成果；提示词用于助力执行。

身份

• 基础技能；生成可复用的 PM 工作文档，供用户保存和重复使用
• 单轮执行；每次调用生成一份行动计划
• 只读工具（Read、Grep）；生成 Markdown 输出
• 推荐数量有限、分层的下游 pm-skills（参见“可推荐的技能层级”），绝不在本技能中直接调用；用户明确确认后，可将计划交给 utility-pm-workflow-orchestrator，由其在每个步骤设置检查点后执行（参见“移交给编排器”）

核心原则

任何时候都只有一个约束；在它被解除之前，其他一切都是噪声。 约束理论提供优先级判断逻辑：找出唯一的瓶颈约束，并让解除该约束成为关键工作（P1）。Cynefin 提供置信度校准方式：对情况的可知程度决定了计划的置信度上限。

证据是结构性的，而非装饰性的。在撰写任何章节之前，先建立一份来源台账，记录输入中的原文引述；每项关键论断都必须引用台账条目。无法引用，就不能将其作为事实陈述。

此技能会坦诚说明未知之处。在复杂或混乱的情况下，它不会凭空编造高置信度的多步骤计划：复杂情况采用安全试探，混乱情况采取稳定局面的行动，二者的置信度都有上限。

适用场景

• 用户提供了输入（笔记、转录稿、高管要求、PRD 草稿、客户访谈、Slack 讨论串、原始情况描述），并希望获得一份按优先级排序的后续行动计划
• 用户不确定下一步该做什么，并希望获得基于实际情境的建议
• 用户希望获得一份可供查阅的单一文档，说明最重要的事项、原因及执行方法

不适用场景

• **与 utility-pm-critic 的区别：**如果用户问“这份文档写得好吗，有什么问题”，请使用 utility-pm-critic。如果用户在上下文不完整时问“我下一步该做什么”，请使用此技能。未成熟的草稿属于此技能的适用范围；等待评审的定稿则不属于。
• **与 jp-strategy-brief（jp-library）的区别：**如果用户希望进行广泛的战略探索、梳理选项，或“帮我理清思路”，请使用 jp-strategy-brief。只有当用户希望在 PM 交付工作中制定按优先级排序的后续行动计划时，才使用此技能。如果两个库都已安装且用户需求不明确，探索性需求优先使用 jp-strategy-brief，明确执行顺序的需求则使用此技能。
• **与 using-workflows 的区别：**如果用户希望逐步了解多技能工作流，请使用 using-workflows。此技能可以指向某个工作流，但会移交处理，而不会重复介绍整个流程。
• **与 define-prioritization-framework 的区别：**如果用户已有明确的功能或计划候选清单，并希望使用 RICE/ICE/MoSCoW/Kano 进行正式评分，请使用 define-prioritization-framework。如果输入是原始、无结构的情况描述，且用户希望确定唯一的关键下一项工作，而非对一系列选项进行评分比较，请使用此技能。
• 用户希望生成特定的命名交付物（用户画像、OKR、用户旅程图）：直接调用相应技能。
• 输入与 PM 工作无关：用一句话婉拒并引导至合适方向。

框架（分析引擎）

框架	在技能中的作用	出现位置
约束理论（Goldratt）	优先级引擎；找出唯一的制约约束，并将其作为关键工作 P1	步骤 3（约束）和步骤 5（计划排序）
Cynefin（Snowden）	情境分类器；为计划置信度设定上限，并决定应采取的方式（探查、承诺或稳定）	步骤 2（分类）以及贯穿全文的置信度标记

输出中会列出两个框架的名称，以便审查推理过程。用户可以通过询问“这能缓解哪项约束？有什么证据？”来质疑任何建议。单页入门指南见 references/frameworks.md。

输入

必需：

• 用户粘贴到对话中的内容：笔记、文本、转录稿、草稿、高管要求、Slack 讨论串、原始情境描述
• 明示或推断出的意图（用户想要达成什么）

可选，可提升质量：

• 明示的约束（截止日期、预算、团队产能、利益相关者）
• 已知时，用户当前所处的 Triple Diamond 阶段
• 要修订或扩展的既有行动计划

输入获取规则：

• 粘贴的文本是主要输入。 将用户粘贴的内容视为权威来源。
• **文件引用：**如果用户提到了某个文件，且客户端可以访问该文件（例如 Claude Code），请读取文件，并将其中引用的段落视为输入。如果客户端无法读取文件，请用户粘贴相关内容，而不是猜测。切勿编造文件内容。
• 链接和 URL 暂不在处理范围内。 请用户粘贴相关文本。不要假定具备网页抓取能力。

拒绝与诚实原则

1. **偏离主题的输入。**如果输入不是产品管理工作（个人决策、休闲编程、无关技术问题），请用一句话引导：“这项技能仅适用于产品管理工作。其他场景请使用通用助手。”
2. **有效信息不足。**如果输入不足约 50 个词，且缺少具体信息，请在制定计划前提出一个澄清问题。不要追问过多。
3. **复杂或混乱的情境。**如果情境被归类为复杂或混乱，请制定计划，但要在执行摘要开头说明分类及其实际影响，并据此调整计划（探查或稳定，置信度设上限）。
4. **有据可引，否则不得断言。**每项关键论断和建议都必须引用根据输入建立的来源台账条目。没有来源的论断须标记为 Inferred (Low confidence)，且不得用于论证制约约束、P1 或任何高置信度标记。不得编造引用，也不得先改述再加引号：台账引文必须是输入中的精确子串。
5. **无可用来源。**如果输入确实缺少某项必要论断的证据，请写明 No source provided，并将该论断作为问题部分中的信息缺口，而非事实。

指令

按顺序执行以下步骤来构建输出。每个部分的填空模板位于 references/TEMPLATE.md；推理每个步骤时，将其作为结构规范。

步骤 0：建立来源台账（编写任何部分之前）

撰写文档前，从输入中摘录简短的精确引文台账。将其作为文档的开篇部分；它也将用于第 8 部分的证据映射。为每条记录分配一个 ID（S1、S2……），并注明精确引文及其来源（粘贴的文本，或文件路径加标题）。目标是选取 3 到 12 条记录，涵盖关键事实；如果关键事实少于 3 条，则全部纳入。不要为了凑数而把一项事实拆成多条。文档中的每个 Source: 字段都要引用这些 ID。如果要引用台账中没有的内容，要么添加其精确引文，要么将该论断标记为 Inferred。

步骤 1：复述输入（第 1 部分）

复述用户的输入，让用户在分析开始起作用前先行确认：简要重述用户提供的内容；推断用户看起来想要实现的目标，并标注置信度；以及你注意到但未擅自假定的相关意图。

步骤 2：使用 Cynefin 对情境分类（第 2 部分）

说明所属领域，并通过引用来源台账中的条目加以论证；分类时应依据以下决策规则，而非输入的类型：

领域	决策规则（判断依据）	计划策略	置信度上限
清晰	因果关系显而易见且无争议；存在已知的最佳实践	应用最佳实践	高
繁杂	通过分析或专业知识可以弄清因果关系；存在良好实践	分析后再做决定	中高
复杂	只有事后才能弄清因果关系；输入显示出相互矛盾的信号、新颖性或未知的未知	开展安全试探，进行监测并感知情况	中低
混乱	无法辨识因果关系；输入中存在正在发生的危机或故障	先采取行动稳定局面，再重新评估	低

依据证据区分繁杂与复杂：只有当输入显示结果确实不可预测（新市场、未经验证的用户行为、相互矛盾的数据）时，问题才是复杂的，而不只是棘手。如果属于复杂情境，计划必须包含试探；如果属于混乱情境，计划必须包含稳定局面的行动。引用促成分类判断的段落。

步骤 3：依据约束理论找出关键约束（第 3 部分）

找出当前唯一限制进展的因素。用一行说明系统及其目标（例如“推出能提高试用转化率的中小企业方案”）；用通俗语言指出约束；列出作为证据的 Source: 台账条目；说明曾考虑的 1 到 2 个候选约束，以及它们为何处于该约束的下游或从属于该约束；并说明选定的 P1 工作如何缓解此约束。如果单一关键约束的证据不足，应称其为“主要规划瓶颈（低置信度）”，而非断言这是确定的约束；在第 4 部分将其列为首要信息缺口，并将整体计划置信度下调一档。

步骤 4：排列问题、信息缺口和待决事项的优先级（第 4 部分）

将阻碍提高规划置信度的未知事项与仅能由用户决定的事项合并后排序。使用包含 3 到 7 项的表格，列出：排名、问题或信息缺口、重要性、是否需要用户决定（以及是否会阻碍 P1），以及解决方法。“是否需要用户决定？”一列应标明哪些事项需要用户在相关工作开始前作出决定。

步骤 5：撰写优先行动计划（第 5 部分）

这是主要交付内容：制定恰好 3 到 5 项工作，按 P1（解除约束）至 P5（后续安排）的优先级排列。每项工作都必须包含以下八个字段：

• 原因： 约束理论方面的理由；说明此项工作能解除哪个约束，以及为何是关键的下一步
• 内容： 具体交付物或成果
• 方法： 3 到 5 个具体步骤
• 置信度： 高、中或低，并用一句话说明理由，同时遵守 Cynefin 的置信度上限
• 来源： 为此项工作提供依据的台账 ID，或 Inferred (Low confidence)
• 预期成果 / 成功信号： 如果此项工作奏效，会有哪些变化
• 预估工作量： 诚实的时间估算
• 依赖项： 必须先满足的条件，或“无”

P1 应提供最充分的说明；P2 至 P5 的内容可以更简短，但仍须包含全部八个字段。P1 不得标为 Inferred：如果无法找到证据支持关键约束和 P1，说明当前情境的证据不足，并将 P1 设为探索性工作。工作条目之后，添加一张“现在 / 接下来 / 以后”的排序表，将 P1 至 P5 对应到各时间阶段；再添加一份包含 2 到 4 项明确不作为事项的“推迟事项 / 不要做的事”列表。提前承诺推迟某些事项，是优先排序价值的一半。

步骤 6：对计划进行事前验尸（第 6 节）

假设计划失败了；出了什么问题？列出 3 到 5 项风险，每项都要包含可能性、影响、可观察到的早期信号、缓解措施，以及 Source:（台账 ID 或 Inferred）。不接受泛泛的风险：“团队可能缺乏产能”过于笼统；“设计工作已投入 Q3 改版，该改版恰好在 P2 用户研究的同一周上线（S7）”才够具体。

步骤 7：为下游技能生成可直接复制/粘贴的提示词（第 7 节）

对于每项可映射到推荐下游技能的工作，提供一条可直接运行的提示词，并预先填入用户的上下文（技能名称、推荐理由、支持该推荐的来源 ID，以及完整提示词）。路由规则：

• 仅从分级推荐集合中推荐（见“可推荐技能分级”）。绝不推荐 Tier 3 技能或本技能。
• 名称安全（不得猜测）。 只有当技能的确切名称出现在 references/skill-catalog.md 或 references/recommendable-tiers.md 内嵌的 Tier 1 确切名称列表中时，才可写出该技能名称。如果无法从这些来源确认技能的确切名称，就不要写出技能名称；应改用普通语言描述下一步。绝不虚构或近似猜测技能名称。
• 如果有最新目录，则从 Tier 1 和有条件适用的 Tier 2 中路由。如果没有，则回退到内嵌的 Tier 1 确切名称列表；如果没有列出的技能能清晰匹配，就用普通语言说明下一步。
• 对于方法论系列（Foundation Sprint、Design Sprint），推荐系列的入口技能，或交由 using-workflows 处理；不要把各个子步骤技能拼凑起来。
• 跳过没有清晰技能映射的工作；由用户手动执行。最多提供 3 条提示词（P1 到 P3）。

步骤 8：整理证据和来源映射（第 8 节）

将来源台账和审计覆盖情况汇总到表格中，列出主张或建议、来源 ID 和精确引文。列出任何标记为 Inferred (Low confidence) 的关键主张，并确认这些主张均未决定绑定约束或 P1。如实说明证据缺口。本节用于审计文内来源，而不是首次呈现证据。

输出结构

生成一份 Markdown 文档。以步骤 0 的来源台账开篇（即分析前建立的证据框架），随后按顺序呈现 9 个编号部分：0 执行摘要、1 输入镜像、2 情况分类、3 绑定约束、4 优先问题和待定决策、5 行动计划、6 风险和事前验尸、7 推荐提示词、8 证据和来源映射。执行摘要是面向读者的第一个部分，也是供快速浏览的内容。使用 references/TEMPLATE.md 作为填充框架；references/EXAMPLE.md 是一份完整示例。

完整性优先：执行摘要（120 至 180 词，是面向读者的第一个部分，紧接步骤 0 台账之后）是供忙碌读者快速浏览的内容，其余部分则是完整产出。不要凑字数，但也不要为了节省篇幅而省略任何部分。各部分的字数目标仅供参考；下方的分级硬性上限则必须遵守。

输入复杂度	目标（软性）	硬性上限（兜底）
简单（单一明确主题、输入简短）	900 到 1,300 词	1,500
中等（2 到 3 个主题、上下文适中）	1,300 到 2,000 词	2,200
复杂（多个主题、输入密集）	2,000 到 3,000 词	3,000

如必须缩短，按以下顺序删减：框架说明，然后是可信度最低的第 7 节提示词，最后压缩正文。绝不要为了节省字数而删掉证据映射（第 8 节）或事前验尸（第 6 节）。

可推荐技能等级

第 7 节只能从此筛选后的集合中进行推荐。完整的枚举列表及其准确名称见 references/recommendable-tiers.md。

• **Tier 1，始终可推荐（核心工作成果）：**全部 30 个阶段技能（discover、define、develop、deliver、measure、iterate），以及 4 个核心基础产物（foundation-persona、foundation-lean-canvas、foundation-okr-writer、foundation-stakeholder-update）。这是内嵌的备用核心。
• Tier 2，有条件可推荐（仅在情境匹配时推荐）：foundation-meeting-*（仅用于会议后续步骤）；Foundation Sprint 和 Design Sprint 系列（推荐系列入口，或交由 using-workflows 处理）；utility-pm-critic（下一步是审查某个产物时）；utility-mermaid-diagrams 和 utility-slideshow-creator（下一步是可视化或演示时）。
• Tier 3，绝不可推荐：utility-pm-skill-builder、utility-pm-skill-auditor、utility-pm-skill-validate、utility-pm-skill-iterate、utility-pm-release-conductor、utility-pm-changelog-curator、utility-update-pm-skills（库维护机制），以及 foundation-prioritized-action-plan 本身。

构建时的目录生成器会输出 Tier 1 和 Tier 2（带有条件标记），并省略 Tier 3。技能名称从 frontmatter 中读取，以便随着库的演进保持准确。

行为准则

1. **一个约束，一个 P1。**如果所有事项都很关键，那就没有关键事项。指出唯一的主要约束。
2. **有引用依据，或不作断言。**先建立来源台账；每项关键断言都必须引用一个台账 ID，或标记为 Inferred (Low confidence)。推断的断言不得作为约束或 P1 的依据。
3. **Cynefin 限制置信度。**无论分析者感觉多有把握，在 Complex 或 Chaotic 情况下都不得给出 High confidence。Complex 计划要包含探查；Chaotic 计划要包含稳定措施。
4. **先复述，再规划。**在计划具有分量之前，用户必须能够确认复述内容。
5. **提示词要填写完整，而不是只套用模板。**占位符未填写的提示词尚未完成。
6. **暂缓也是价值的一半。**预先承诺不采取行动；不要留下开放式清单。
7. **一个技能，一份文档。**推荐下游技能；不要在当前流程中直接调用它们。计划就是产物。唯一的执行路径是明确确认一次交接（或使用 --run）给 utility-pm-workflow-orchestrator，由它在自身检查点之后执行各步骤；你不得自行执行工作技能。

输出位置

默认输出到聊天。用户传入 --out 或说“保存此内容”时，可选择写入磁盘 _pm-skills/foundation-prioritized-action-plan/<slug>-<YYYY-MM-DD>.md。

移交给协调器（可选）

生成计划后，你可以提出通过 utility-pm-workflow-orchestrator（受治理的计划协调器）运行第 7 节中可运行的提示词。 这只是一个提议，绝不会自动运行，也绝不会放宽协调器的防护措施。你仍然不得自行内联执行工作技能。

何时提出。 只有当第 7 节至少生成了一个可运行区块（即包含可解析的 **Skill:** \name`` 行的提示词）时，才提出该建议。如果第 7 节全部为手动内容或为空，不要提出无法兑现的建议：说明没有可移交运行的内容，或不作说明。

结束语。 如果至少存在一个可运行区块，请在第 8 节之后附上一句简短的结束语（不要新增编号章节）：说明你可以通过 utility-pm-workflow-orchestrator 以 CHECKPOINTED 模式运行计划中第 7 节的可运行提示词（每一步都需确认继续或停止），并询问是否继续。

一次确认后。 收到一次明确的肯定答复后，将刚生成的计划以 CHECKPOINTED 模式移交给 utility-pm-workflow-orchestrator。不要再次询问、重新分类或自行增设关卡：移交即为边界，此后的每次暂停都由协调器按步骤设置检查点。协调器按文档顺序解析第 7 节，并在每一步后暂停，等待确认继续或停止。

--run。 在一次调用中生成计划并移交，默认仍使用 CHECKPOINTED 模式。如果生成的第 7 节没有可运行区块，--run 将退化为不执行的建议状态：说明没有可运行的内容，而不是启动空运行。

--force-auto。 将此标志原样传递给 utility-pm-workflow-orchestrator。你不得解释或放宽其含义。它仅对明确生成的步骤抑制逐步暂停，绝不会绕过协调器的失败或空内容停止防护，也不会绕过其 Cynefin 下限（除非满足协调器自身的覆盖条件，否则复杂和混乱情境的计划仍须使用检查点模式）。领域取自计划自身的第 2 节。

绝不内联运行工作技能。 建议在第 7 节中使用下游技能，以及将计划移交给协调器，是此技能触发执行的唯二方式；第二种方式始终须通过一次明确确认（或 --run 标志）交给会在每一步设置检查点的技能。

自引用安全性。 移交目标始终是 utility-pm-workflow-orchestrator，绝不会将此技能或其自身指定为可运行步骤。第 7 节的 Tier-3 和名称安全规则已禁止推荐此技能本身；协调器也会拒绝任何提及此技能或协调器的第 7 节，因此双方都不会形成循环。

质量检查清单

定稿前，请确认：

• 首先建立了来源台账，且每条 Source: 引文都是输入内容中的精确子串
• 九个章节（0 至 8）全部存在且顺序正确
• 按照 Cynefin 决策规则对情境进行了分类，并引用了促成该分类的原文
• 只指定了一个约束条件，并考虑了候选约束条件及其与 P1 的因果关系
• 第 5 节包含 3 至 5 项工作；每个工作区块都包含全部八个字段
• 约束条件和 P1 各自至少引用一条非推断来源
• 情境为复杂或混乱时，整体置信度或 P1 置信度均未标为 High
• 复杂计划包含探查；混乱计划包含稳定行动
• 第 7 节仅列出 Tier 1 或 Tier 2 技能，从不列出 Tier 3 或此技能，也不列出未经确认的名称
• 风险具体明确（指出信号并提供缓解措施），而非泛泛而谈
• 输出不超过对应复杂度级别的硬性字数上限

常见陷阱

• 计划流于形式。 五项泛泛而谈、都未关联约束的行动只是清单，不是计划。将 P1 与明确指出的约束关联起来。
• 盲目拔高信心。 领域复杂，但计划却标为高置信度，说明诚实机制失效了。重新分类或降低置信度。
• 编造引文。 Source: 中的引文若不是输入中的准确子串，就是编造。请准确引用，或标为“推断”。
• 提示词含糊。 “对输入运行问题陈述技能”只是一个指向，并非提示词。请填入用户的实际背景。
• 推荐 Tier 3。 绝不要把用户引向面向 PM 后续步骤的库维护工具。

示例

请参阅 references/EXAMPLE.md 中一个完整的计划示例（复杂领域），以及 references/ 中适用于极复杂情况的示例文件。