从零散 PM 输入生成有证据支撑的优先级行动计划（含约束识别…

当你手头只有笔记、访谈记录、高管诉求或 Slack 讨论等原始材料，需要一份可保存、可执行、带证据引用的下一步行动优先级计划时使用。

适用场景

解决思路

1. 先构建来源台账（source ledger）：在写任何章节前，从输入中提取 3 到 12 条精确原文引用，每条给 ID（S1、S2…）、原文和出处（粘贴文本或文件路径加标题），作为文档开头块，后续所有 Source 字段都引用这些 ID；若想引用台账外内容，要么补上精确引用，要么标记为 Inferred。
2. 镜像输入（Section 1）：简洁复述用户给了什么、推断其意图（附置信度）、以及注意到但未假定的相邻意图，让用户先确认再让分析生效。
3. 用 Cynefin 分类情境（Section 2）：按决策规则而非输入体裁判断——Clear（因果明显、有最佳实践）、Complicated（可分析得知、有良好实践）、Complex（仅事后可见、信号冲突/新颖/未知未知）、Chaotic（无因果、危机中）；分别对应应用最佳实践、分析后承诺、安全失败探针、先稳定；置信度上限依次为 High、Medium-High、Medium-Low、Low；引用驱动分类的原文。
4. 用约束理论（TOC）命名唯一约束（Section 3）：一行说明系统与目标，用平实语言命名约束，给出证据的 Source 台账条目，列出 1 到 2 个被考虑但属于下游或从属的候选约束，并说明 P1 努力与缓解该约束的因果链；若证据薄弱，改称“主要规划瓶颈（低置信度）”，在 Section 4 标为头号缺口，并将整体计划置信度降一档。
5. 排序问题、缺口与待决事项（Section 4）：用 3 到 7 行表格列出排名、问题或缺口、为何重要、是否需要用户决策（及是否阻塞 P1）、如何解决。
6. 撰写优先级行动计划（Section 5）：恰好 3 到 5 项努力，从 P1（解除约束）排到 P5；每项包含全部八个字段——Why（TOC 推理，解除哪个约束）、What（具体交付物或结果）、How（3 到 5 个具体步骤）、Confidence（High/Medium/Low 加一行理由，遵守 Cynefin 上限）、Source（台账 ID 或 Inferred (Low confidence)）、Expected outcome / success signal、Estimated effort（诚实时间估计）、Dependencies（前置条件或 none）；P1 最详细，P2 到 P5 较短但保留全部八字段；P1 不得为 Inferred，若无法溯源则把 P1 设为发现性努力；之后加 Now / Next / Later 排序表，以及 2 到 4 条“推迟/不要做”的明确非行动清单。
7. 做预演失败分析（Section 6）：假设计划已失败，列出 3 到 5 个风险，每个含可能性、影响、早期可观察信号、缓解措施和 Source（台账 ID 或 Inferred）；风险必须具体（如“设计已承诺 Q3 改版，与 P2 用户研究同周落地（S7）”），不能泛泛而谈。
8. 生成下游技能的可复制粘贴提示（Section 7）：为每项能映射到可推荐下游技能的努力提供已填入用户上下文的现成提示（技能名、为何用此技能、支撑的 source ID、完整提示）；只从分层可推荐集合中推荐（Tier 1 始终可推荐：30 个阶段技能加 foundation-persona、foundation-lean-canvas、foundation-okr-writer、foundation-stakeholder-update；Tier 2 条件推荐：foundation-meeting-*、Foundation Sprint 与 Design Sprint 家族入口、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）或本技能自身；技能名必须出现在 references/skill-catalog.md 或 references/recommendable-tiers.md 的 Tier 1 精确名单中，否则不得命名，改用平实语言描述下一步；方法论家族推荐家族入口或交给 using-workflows；无干净映射的努力跳过；最多 3 条提示（P1 到 P3）。
9. 汇总证据与来源映射（Section 8）：用表格列出主张或建议、source ID、精确引用；列出所有 Inferred (Low confidence) 的承重主张并确认它们不驱动约束或 P1；诚实说明证据缺口。
10. 按输出结构组装：一份 markdown 文档，先放 Step 0 来源台账，再按顺序放九个编号章节（0 执行摘要、1 输入镜像、2 情境分类、3 约束、4 问题与待决事项、5 行动计划、6 风险与预演失败、7 推荐提示、8 证据与来源映射）；执行摘要 120 到 180 词，是快速浏览层；用 references/TEMPLATE.md 作填充脚手架，references/EXAMPLE.md 为完整样例。
11. 遵守字数上限：简单输入目标 900 到 1300 词、硬上限 1500；中等 1300 到 2000、硬上限 2200；复杂 2000 到 3000、硬上限 3000；若需缩短，按顺序削减框架解释、最低置信度的 Section 7 提示、压缩行文，绝不删掉证据映射（Section 8）或预演失败（Section 6）。
12. 遵守行为护栏：一个约束一个 P1；先引用再主张；Cynefin 封顶置信度（Complex/Chaotic 拒绝 High）；先镜像后计划；提示要填满不留占位符；预先承诺推迟；一个技能一份文档，只推荐下游技能绝不内联调用。
13. 可选交接：仅当 Section 7 至少有一个可运行块（含可解析的 **Skill:** `name` 行）时，在 Section 8 后加一句简短收尾，说明可将可运行提示交给 utility-pm-workflow-orchestrator 以 CHECKPOINTED 模式运行并询问是否继续；用户一次明确确认后交接，不再重新提示或加自己的门；--run 表示产出计划并同时交接（仍默认 CHECKPOINTED，若无运行块则退化为无操作）；--force-auto 原样转发给编排器，绝不解释或放宽；绝不内联运行工作技能。
14. 输出目的地：默认聊天输出；当用户传 --out 或说“save this”时可选写入 _pm-skills/foundation-prioritized-action-plan/<slug>-<YYYY-MM-DD>.md。
15. 完成前对照质量清单：来源台账先建且每条 Source 引用是输入的精确子串；九个章节（0 到 8）齐全有序；用 Cynefin 决策规则分类并引用驱动段落；恰好一个约束并考虑候选与 P1 因果链；Section 5 有 3 到 5 项努力且每项八字段齐全；约束与 P1 各至少引用一个非 Inferred 来源；Complex/Chaotic 时整体或 P1 置信度不得为 High；Complex 计划含探针、Chaotic 计划含稳定行动；Section 7 只命名 Tier 1 或 Tier 2 技能，绝不 Tier 3 或本技能，绝不未确认名称；风险具体；输出在复杂度对应硬上限内。

适用边界 · 注意事项

• 用户问“这个产物好不好、有什么问题”时，应使用 utility-pm-critic；本技能用于“下一步该做什么”且上下文不完整时，半成品草稿在范围内，待评审的成品不在。
• 用户想要广泛战略探索、选项框定或“帮我想清楚”时，应使用 jp-strategy-brief；本技能只用于 PM 交付工作中要一份排序的下一步行动计划。
• 用户已有明确的候选功能或举措清单并想要正式 RICE/ICE/MoSCoW/Kano 评分时，应使用 define-prioritization-framework；本技能用于原始非结构化情境。
• 用户想要多技能工作流走查时，应使用 using-workflows；本技能可指向工作流但只交接不复制。
• 用户想生成某个具体命名产物（persona、OKR、旅程图）时，直接调用对应技能。
• 输入与 PM 工作无关时，用一行重定向拒绝。