sprint-planning（迭代规划） 是这套产品管理技能里最轻量、也最贴近执行层的一个技能。它抓住了迭代规划里最容易被忽略的三件事：容量、范围和风险 ，并把它们整理成清楚的决策框架。
系列说明： 属 Anthropic 官方产品管理技能系列。放在整套工作流里，它最接近执行起点，负责把中期规划收束到当前这一轮迭代。
一、这个技能在解决什么问题#
很多迭代规划之所以低效，往往是因为计划阶段默认了几个并不成立的前提：
- 所有人都满额可用
- 待办列表优先级已经清楚
- 结转事项不会影响新承诺
- 依赖项不会临时爆炸
- 计划容量可以拉满
sprint-planning 的设计，正是为了把这些常见误判提前摊开。 它并不替代工程计划工具，更接近一个足够清楚的迭代规划骨架。
二、技能定位#
它的定义是：name 为 sprint-planning，description 是界定工作范围、估算容量、设定目标、起草迭代计划 ，argument-hint 则是 [迭代名称或日期范围]。相比其他技能，这个技能的定位更偏执行。它不承担复杂分析，主要是帮助团队快速进入一次高质量迭代计划所需的核心要素。
三、工作流的重点非常明确#
1. 它先问团队最关键的输入#
sprint-planning 要的内容包括团队与可用时间、迭代时长、待办列表、结转事项、依赖项 。这五项刚好对应了一次迭代规划里最容易被低估的现实变量。
尤其是可用时间 这一项。很多团队做规划时默认每个人整个周期都能投入功能开发，结果计划从第一天开始就不成立。这个技能明确要求把休假、会议等因素算进去，这个方向很对。
2. 它区分独立运行和增强模式#
这个技能用很直观的方式展示了独立运行和增强模式 两种形态：前者即使没有工具也能工作，后者在接入项目追踪工具、日历、聊天工具后能力增强。这样的写法虽然比其他技能更轻，但效果很好，用户一眼就知道它的基础价值，也能看清工具连接在这里扮演的是增强角色。
3. 输出围绕迭代决策最需要的结构#
它的输出模板包括迭代目标、容量表、迭代待办表、迭代负载与计划容量对比、风险、完成定义、关键日期 。这样的设计比单纯列任务清单成熟得多，因为它在规划阶段就把几个绕不过去的问题摆到了桌面上：本次迭代到底想完成什么，负载是否超标，哪些是 P0 / P1 / P2，哪些风险已经可见。
四、它虽然轻量，但还是体现了几个关键规划原则#
1. 计划不是把容量拉满#
在提示里，它明确建议只规划 70%-80% 的容量 。这是非常现实的经验规则。很多团队迭代失败，问题往往就埋在规划阶段：一开始就按理想状态估算，没有给中途扰动留下空间。
2. 一个迭代应该有明确目标#
它强调：如果迭代目标无法用一句话说明，这次迭代多半就不够聚焦 。这个要求看似简单，却点中了很多团队迭代质量不高的症结：任务不少，却没有清晰的共同目标。
3. 扩展项必须被显式标出来#
很多团队会把扩展项和承诺项混在一起，最后对外预期不清楚，复盘时也很难判断是否过度承诺，团队的心理负担也会随之上升。把 P0 / P1 / P2 直接写在迭代待办表里，是个很实用的设计。
五、一个典型使用场景#
假设用户说：
/sprint-planning Sprint 24一个好的工作流会立刻去确认：团队成员本次可用时间 ，待办列表里优先级最高的事项 ，上一轮有哪些结转事项 ，哪些工作依赖外部团队 ，以及这次迭代最重要的单句目标是什么 。最后输出的也不该只是一个”所有人都很忙”的表格，而应该是一份真正能回答这些问题的计划：这轮到底承诺什么，负载是否合理，哪些属于扩展项，哪些风险已经可见，关键节奏点又落在哪些日期。
六、与其他技能的关系#
它的上游通常是 roadmap-update 和 write-spec ，因为迭代规划的前提是中期优先级已经有基本方向，核心需求也有足够清晰的定义。它的下游常常是 stakeholder-update ，因为规划结果往往还要同步给团队或跨团队伙伴。
七、小结#
sprint-planning 盯住的正是迭代规划最关键的现实约束：可用时间、容量、范围、风险、结转事项 。从智能体设计角度看，它也给了一个很直接的启发：执行层任务未必需要厚重的方法论；结构清楚、边界明确、输出稳定的轻量技能，同样很有价值 。