task-planning

任务规划

当工作需要将杂乱的上下文整理成一份团队真正能据此行动的精简规划包时，请使用此技能。

task-planning 是 PM 处理待办清理、功能拆分、冲刺候选项准备、发布分批、里程碑规划包，以及在估算、看板、评审或执行之前将路线图转化为交付计划的入口。

核心参考资料：

• references/intake-packets-and-route-outs.md
• references/packet-shapes.md
• references/readiness-checklist.md
• references/planning-patterns.md
• references/sprint-planning-recipe.md — 当规划包是冲刺候选项，且团队有速度历史数据时使用

何时使用此技能

• 请求过于模糊、范围过大或内容混杂，无法直接交给实施团队。
• 需要清理待办，将工作分为已就绪和未就绪。
• 路线图事项、功能、Bug 集合、发布节点或试玩反馈需要拆分为可执行任务。
• 团队需要一份简洁的规划包，明确列出依赖项、阻碍因素和验收标准。
• 规划包涉及多个职能领域：前端/后端、PM/运营、GTM/内容，或代码/内容/构建/试玩工作。
• 核心问题是“接下来实际该做什么？”，而不是“工作量有多大？”或“该用哪个看板？”

何时不使用此技能

• 主要工作是工作量估算、预测或故事点相关事务 → 使用 task-estimation。
• 工作已存在，真正要做的是变更事项状态 → 使用 triage。
• 计划已经存在，真正要做的是评审/审批或差异标注 → 使用 plannotator。
• 主要工作是协调每日进度 → 使用 standup-meeting。
• 主要工作是复盘已完成的工作 → 使用 sprint-retrospective。
• 工作仍处于概念框定、范围调整或游戏制作统筹阶段，尚未拆分 → 先使用 bmad、bmad-idea 或 bmad-gds。

说明

第 1 步：选择一个接收规划包

使用 references/intake-packets-and-route-outs.md，并且只选择一个主要规划包：

task_planning_packet:
  packet: backlog-cleanup | feature-slice | sprint-candidate | release-packet | milestone-packet | discovery-first
  domain: developer-workflow | web-fullstack | product-ops | marketing-gtm | game-development | mixed
  source_material: repo/issues | prd/spec | gdd/playtest | launch-notes | chat-context | mixed | unknown
  readiness_state: mostly-ready | mixed | mostly-fuzzy
  output_shape: single-packet | slice-table-plus-not-ready | release-packet | milestone-packet | discovery-packet

规划包含义：

• backlog-cleanup — 澄清、去重，并区分已就绪和未就绪的工作。
• feature-slice — 将一项功能或一组 Bug 拆分为可分配的任务。
• sprint-candidate — 为下一次迭代准备已就绪的工作。
• release-packet — 规划发布、推广、营销活动或正式上线工作。
• milestone-packet — 协调跨职能的里程碑或演示工作，尤其适用于游戏。
• discovery-first — 在假定实施已就绪之前，先梳理未知事项。

第 2 步：收集最低限度且可信的证据

不要仅凭感觉做规划。收集足以支持任务拆分的最小规划包：

• 目标或问题陈述
• 用户、业务、团队或玩家成果
• 当前资料：事项、规格文档/PRD、GDD、发布说明、试玩记录、Bug 列表或聊天上下文
• 时间线或触发条件：冲刺、发布、里程碑、活动或依赖窗口
• 明显的约束：负责人、平台、环境、审批、外部依赖
• 可能导致规划包看似就绪、实则未就绪的缺失信息

如果证据不足，请明确说明，并选择 discovery-first，不要凭空编造确定性。

第 3 步：尽早拆分探索与交付

编写任务切片之前，先区分：

1. 探索 — 尚未解答的问题、验证工作、缺失的决策
2. 基础工作 — 设置、架构、共享资源、工具、环境
3. 交付 — 面向用户或系统的实施任务切片
4. 验证 — QA、分析、评审、冒烟测试、试玩、发布检查
5. 后续工作 — 文档、赋能、推广、报告、监控、分发

不要把研究工作或尚未解决的决策塞进构建工单中。

第 4 步：选择最精简的数据包形态

使用 references/packet-shapes.md。

规则：

• 如果用户只需要一组后续行动，优先使用单个数据包。
• 如果主要需求是区分已就绪与未就绪事项，使用切片表加未就绪事项列表。
• 如果工作与发布窗口相关，使用发布数据包。
• 如果工作包含许多里程碑且涉及多个学科，使用里程碑数据包。
• 如果数据包开始同时承担任务分解、估算、看板控制、评审和仪式流程工作，应拆分职责并转交给其他流程。

第 5 步：使用就绪状态字段构建切片

每个切片应包含：

• 标题
• 结果
• 负责人角色
• 依赖项
• 所需输入
• 验收标准
• 风险 / 不确定性
• 是否就绪？是 / 否
• 若未就绪，缺少什么？

使用简短、可测试的验收标准。避免使用“效果更好”或“已准备好发布”这类模糊表述。

第 6 步：明确顺序和阻塞项

明确指出：

• 哪些工作可以并行开展
• 哪些工作必须按顺序进行
• 哪些工作受阻
• 哪些工作应延期

使用 references/readiness-checklist.md 中的阻塞项类别：

• missing-scope
• missing-design
• missing-data
• external-dependency
• environment-access
• approval-needed
• cross-team-handoff

第 7 步：执行流程转交检查

确认以下各项：

1. 所选数据包符合实际规划需求。
2. 信心不足时，将探索与实施分开。
3. 数据包不会悄然接管规模估算、看板控制、计划评审、站会或回顾工作。
4. 保留跨领域的细节，不要把输出写成教程。
5. 数据包以一个明确的下一步行动收尾。

明确转交给以下流程：

• 规模估算 → task-estimation
• 问题状态变更 → triage
• 计划评审 / 审批 → plannotator
• 每日协调 → standup-meeting
• 已完成工作的回顾 → sprint-retrospective
• 概念框定 / 策略塑造 → bmad、bmad-idea、bmad-gds

第 8 步：返回简报或最终数据包

完整起草前，优先采用以下简报格式：

# Task Planning Brief

## Packet choice
- Packet:
- Domain:
- Why it fits:
- Output shape:

## Source material used
- Main evidence:
- Constraints / dependencies:
- Assumptions / gaps:

## Planned slices
1. slice
2. slice
3. slice

## Route-out notes
- Out of scope:
- Not-ready work kept separate:
- Recommended next move:

如果用户已经要求最终产物，直接返回精简的规划数据包。

输出格式

默认数据包形态：

# Planning Packet

## Planning horizon
- Packet:
- Domain:
- Confidence: high | medium | low

## Goal
- ...

## Assumptions
- ...

## Work slices
| Slice | Outcome | Owner role | Dependencies | Ready? |
|------|---------|------------|--------------|--------|
| ... | ... | ... | ... | yes/no |

## Slice details
### 1. [Slice name]
- Inputs required:
- Acceptance criteria:
  - [ ] ...
- Risks / uncertainty:
- Notes:

## Sequencing
1. ...
2. ...

## Blockers / not-ready items
- Bucket:
- Missing:
- Next action:

## Recommended next move
- start implementation | run discovery first | groom with owners | estimate now | defer until dependency clears

示例

示例 1：全栈功能切片

输入

为我们的 SaaS 应用拆解新的团队邀请流程。我们需要在冲刺规划前完成邮件邀请、邀请接受和管理员可见性。

良好的输出方向

• 数据包：sprint-candidate
• 领域：web-fullstack
• 拆分为后端 / 数据、邀请接受流程、管理员可见性、验证和后续跟进
• 不涉及故事点

示例 2：待办事项清理

输入

我们有一堆描述模糊的引导流程待办事项。请整理它们，以便我们了解下周哪些事项真正就绪。

良好的输出方向

• 数据包：backlog-cleanup
• 输出形态：slice-table-plus-not-ready
• 明确标出缺失的范围、负责人或审批
• 将探索任务与实施任务分开

示例 3：营销 / 发布数据包

输入

为我们的 B2B 发布规划下一轮推广：着陆页更新、邮件序列、归因检查和发布日汇报。

良好的输出方向

• 数据包：release-packet
• 领域：marketing-gtm
• 分别安排素材制作、评审 / 审批、分发、衡量和汇报
• 将深入的文案撰写 / 营销活动执行转交给 marketing-automation

示例 4：游戏里程碑数据包

输入

为我们的 roguelike 演示版规划下一个里程碑：优化教程、支持控制器，并准备好适合主播使用的构建版本。

良好的输出方向

• 数据包：milestone-packet
• 领域：game-development
• 分别安排代码 / 系统工作、内容 / 优化、构建 / QA，以及试玩 / 分发相关事项
• 如有需要，将更广泛的游戏制作协调工作转交给 bmad-gds

最佳实践

1. 拆解工作前，先选择一个主要工作包。
2. 需求尚不稳定时，将探索与交付分开。
3. 优先选择小而易于审查的工作切片，而不是宽泛的工作类别。
4. 明确指出阻碍因素和缺失输入，不要将它们埋在备注中。
5. 保留开发者工作流、Web/全栈、产品/运营、营销/GTM 和游戏工作的领域细节，同时避免让入口过于臃肿。
6. 将工作量估算、看板管理、审查、日常节奏和回顾安排到其他环节，避免扩大技能边界。
7. 工作包应保持精简，让团队能够立即采取行动。
8. 角色描述发生重大变化时，更新精简版和清单中的发现入口。

参考资料

• Atlassian — 待办事项梳理
• Atlassian — Sprint 规划
• GitHub 文档 — 关于 Projects
• GitHub 文档 — 关于里程碑
• HacknPlan 文档