Task Planning

Task Planning

Use this skill when the job is turning messy context into one small planning packet that a team can actually act on.

task-planning is the PM front door for backlog cleanup, feature decomposition, sprint-candidate prep, release slicing, milestone packets, and roadmap-to-delivery translation before estimation, boards, review, or execution.

Core references:

• references/intake-packets-and-route-outs.md
• references/packet-shapes.md
• references/readiness-checklist.md
• references/planning-patterns.md
• references/sprint-planning-recipe.md — when the packet is a sprint candidate and the team has velocity history

When to use this skill

• The request is too vague, too large, or too mixed to hand straight to implementation.
• A backlog needs to be cleaned into ready vs not-ready work.
• A roadmap item, feature, bug cluster, launch beat, or playtest finding needs execution slices.
• A team needs one compact packet that names dependencies, blockers, and acceptance criteria.
• The packet spans multiple disciplines: frontend/backend, PM/ops, GTM/content, or code/content/build/playtest work.
• The key question is "what should we actually do next?" rather than "how big is it?" or "what board should we use?"

When not to use this skill

• The main job is sizing, forecasting, or story-point language → task-estimation.
• The work already exists and the real job is issue state transitions → triage.
• The plan already exists and the real job is review/approval or diff markup → plannotator.
• The main job is daily status coordination → standup-meeting.
• The main job is reflection on completed work → sprint-retrospective.
• The work is still concept framing, scope shaping, or game-production orchestration before decomposition → bmad, bmad-idea, or bmad-gds first.

Instructions

Step 1: Choose one intake packet

Use references/intake-packets-and-route-outs.md and pick exactly one primary packet:

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

Packet meanings:

• backlog-cleanup — clarify, dedupe, and separate ready from not-ready work.
• feature-slice — turn one feature or bug cluster into assignable slices.
• sprint-candidate — prepare the next iteration's ready work.
• release-packet — shape launch, rollout, campaign, or go-live work.
• milestone-packet — coordinate cross-discipline milestone or demo work, especially for games.
• discovery-first — expose unknowns before pretending implementation is ready.

Step 2: Gather the minimum credible evidence

Do not plan from vibes alone. Pull the smallest packet that supports decomposition:

• goal or problem statement
• user, business, team, or player outcome
• current artifacts: issues, spec/PRD, GDD, launch notes, playtest notes, bug list, or chat context
• timeline or trigger: sprint, release, milestone, event, or dependency window
• obvious constraints: owner, platform, environment, approvals, external dependencies
• missing details that could make the packet fake-ready

If evidence is thin, say so and choose discovery-first instead of inventing certainty.

Step 3: Split discovery from delivery early

Before you write slices, separate:

1. Discovery — unanswered questions, validation, missing decisions
2. Foundation — setup, architecture, shared assets, tooling, environments
3. Delivery — user-facing or system-facing implementation slices
4. Verification — QA, analytics, review, smoke tests, playtests, launch checks
5. Follow-through — docs, enablement, rollout, reporting, monitoring, distribution

Do not bury research or unresolved decisions inside build tickets.

Step 4: Choose the smallest packet shape

Use references/packet-shapes.md.

Rules:

• If the user needs one next-action set, prefer a single packet.
• If the main need is ready vs not-ready triage, use slice table plus not-ready list.
• If the work is tied to a launch window, use a release packet.
• If the work is milestone-heavy and cross-discipline, use a milestone packet.
• If the packet starts doing decomposition, estimation, board control, review, and ceremony work at once, split responsibilities and route outward.

Step 5: Build slices with readiness fields

Every slice should have:

• title
• outcome
• owner role
• dependencies
• inputs required
• acceptance criteria
• risk / uncertainty
• ready? yes / no
• if not ready, what is missing?

Use short, testable acceptance criteria. Avoid vague statements like "works better" or "launch ready".

Step 6: Surface sequence and blockers

Explicitly name:

• what can run in parallel
• what must happen in order
• what is blocked
• what should be deferred

Use blocker buckets from references/readiness-checklist.md:

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

Step 7: Run the route-out check

Verify all of these:

1. The chosen packet matches the real planning job.
2. Discovery is separated from implementation when confidence is low.
3. The packet does not silently absorb sizing, board control, plan review, standups, or retros.
4. Cross-domain nuance survives without turning the output into a tutorial.
5. The packet ends with one clear next move.

Route-outs to keep explicit:

• sizing → task-estimation
• issue state transitions → triage
• plan review / approval → plannotator
• daily coordination → standup-meeting
• completed-work reflection → sprint-retrospective
• concept framing / strategy shaping → bmad, bmad-idea, bmad-gds

Step 8: Return the brief or the final packet

Preferred brief shape before full drafting:

# 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:

If the user already asked for the final artifact, return a compact planning packet directly.

Output format

Default packet shape:

# 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

Examples

Example 1: Fullstack feature slicing

Input

Break down a new team-invite flow for our SaaS app. We need email invites, acceptance, and admin visibility before sprint planning.

Good output direction

• packet: sprint-candidate
• domain: web-fullstack