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

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 board/worktree/queue control → vibe-kanban.
• 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
• board/worktree/queue control → vibe-kanban
• 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
• split backend/data, invite acceptance flow, admin visibility, verification, and follow-through
• keep story points out of scope

Example 2: Backlog cleanup

Input

We have a pile of vague onboarding backlog items. Clean them up so we can see what is actually ready next week.

Good output direction

• packet: backlog-cleanup
• output shape: slice-table-plus-not-ready
• mark missing scope, ownership, or approvals explicitly
• separate discovery tickets from implementation tickets

Example 3: Marketing / launch packet

Input

Plan the next release push for our B2B launch: landing-page updates, email sequence, attribution checks, and launch-day reporting.

Good output direction

• packet: release-packet
• domain: marketing-gtm
• separate asset creation, review/approval, distribution, measurement, and reporting
• route deep copywriting/campaign execution to marketing-automation

Example 4: Game milestone packet

Input

Plan the next milestone for our roguelike demo: tutorial polish, controller support, and a streamer-ready build.

Good output direction

• packet: milestone-packet
• domain: game-development
• separate code/system work, content/polish, build/QA, and playtest/distribution concerns
• keep broader game-production orchestration routed to bmad-gds when needed

Best practices

1. Choose one primary packet before decomposing the work. 2. Keep discovery separate from delivery whenever requirements are unstable. 3. Prefer small, reviewable slices over broad work categories. 4. Surface blockers and missing inputs explicitly instead of burying them in notes. 5. Preserve domain nuance for developer workflow, web/fullstack, product/ops, marketing/GTM, and game work without bloating the front door. 6. Route sizing, board control, review, daily cadence, and retrospectives out instead of stretching the skill boundary. 7. Keep the packet compact enough that a team can act on it immediately. 8. Update compact and manifest discovery surfaces when the role wording changes materially.

References

• Atlassian — Backlog refinement
• Atlassian — Sprint planning
• GitHub Docs — About Projects
• GitHub Docs — About milestones
• HacknPlan Docs

Intake Packets and Route-outs

Use this sheet at the start of every task-planning run.

Choose one intake packet

backlog-cleanup

Use when the input is a pile of vague, duplicated, or mixed-quality work.

Keep:

• dedupe / merge notes
• ready vs not-ready separation
• missing scope / design / owners / approvals
• one recommendation about what is ready now, what needs grooming, and what needs discovery

feature-slice

Use when one feature, bug cluster, or change request needs assignable slices.

Keep:

• smallest meaningful delivery slices
• clear system/workflow boundaries
• acceptance criteria and dependencies
• verification and follow-through slices

sprint-candidate

Use when the job is preparing the next iteration's realistic ready work.

Keep:

• readiness
• blockers
• owner-role clarity
• sequencing and parallelism
• one recommendation about what is ready now vs later

release-packet

Use when the request is tied to a launch, rollout, campaign, or go-live window.

Keep:

• trigger date / event / freeze point
• creation, approval, distribution, verification, and reporting slices
• critical dependencies
• launch-day checks and fallback actions

milestone-packet

Use when work crosses disciplines and converges on a demo, event, or milestone.

Keep:

• code/system work
• content/polish work
• QA/playtest/build/distribution work
• must-have vs stretch scope
• milestone gates and fallback scope

discovery-first

Use when the user wants a plan but the evidence is too thin to commit cleanly.

Keep:

• unanswered questions
• validation tasks
• prerequisite decisions
• missing artifacts or external inputs
• one handoff back into task-planning once uncertainty drops

Route-outs to keep explicit

Smell checks

• If you are assigning points, you are drifting into task-estimation.
• If you are opening boards/worktrees/queues, you are drifting into vibe-kanban.
• If you are annotating or approving the plan itself, you are drifting into plannotator.
• If the output reads like a standup or retro, you are in the wrong lane.
• If the packet still depends on unresolved concept or strategy questions, route back to bmad, bmad-idea, or bmad-gds first.

Modes and Handoffs

Primary planning modes

backlog-cleanup

Use when the input is a pile of vague, duplicated, or mixed-quality work.

Focus on:

• deduping and clarifying items
• separating ready vs not-ready
• identifying missing scope, design, owners, or approvals
• keeping discovery tasks separate from implementation tasks

feature-slice

Use when one feature, bug cluster, or change request needs assignable slices.

Focus on:

• smallest meaningful delivery slices
• system or workflow boundaries
• acceptance criteria and dependencies
• verification and follow-through slices

sprint-candidate

Use when the job is preparing work for the next sprint/iteration.

Focus on:

• readiness
• blockers
• owner-role clarity
• sequencing and parallel work
• one recommendation about what is ready now vs later

release-slice

Use when the request is tied to a launch, campaign, rollout, or release window.

Focus on:

• timing and external deadlines
• approval checkpoints
• distribution, rollout, or communications dependencies
• analytics, reporting, and launch-day checks

milestone-plan

Use when the work crosses disciplines and converges on a milestone, demo, or event.

Focus on:

• code/system work
• content/polish work
• QA/playtest/build/distribution work
• milestone gates and must-have vs nice-to-have boundaries

discovery-first

Use when the user wants planning but the evidence is too thin to commit cleanly.

Focus on:

• unanswered questions
• validation tasks
• prerequisite decisions
• missing artifacts or external inputs

Boundary handoffs

Boundary smell checks

• If you are assigning points, you are drifting toward task-estimation.
• If you are opening boards/worktrees/queues, you are drifting toward vibe-kanban.
• If you are annotating or approving the plan itself, you are drifting toward plannotator.
• If the output reads like a standup or retro, you are in the wrong lane.
• If the packet still depends on unresolved strategy or concept definition, route back to bmad, bmad-idea, or bmad-gds first.

Packet Shapes

Use the smallest output shape that preserves readiness and boundaries.

1. Single packet

Best when one feature, bug cluster, or scoped initiative just needs a compact planning packet.

Include:

• mode + domain
• goal
• assumptions
• work-slice table
• 1-3 slice details
• sequencing
• blockers
• one next move

2. Slice table plus not-ready list

Best for backlog cleanup and triage-heavy work.

Include:

• ready slices table
• not-ready list with missing inputs
• dedupe / merge notes if needed
• recommendation: estimate, groom with owners, or run discovery first

3. Release packet

Best for launch windows, campaigns, rollouts, or time-sensitive deliveries.

Include:

• release trigger or deadline
• slices for creation, approval, distribution, verification, and reporting
• critical dependencies and freeze points
• launch-day or release-day checks

4. Milestone packet

Best for game milestones, demos, or cross-discipline delivery windows.

Include:

• milestone goal
• must-have vs stretch work
• code/system slices
• content/polish slices
• QA/playtest/build/distribution slices
• risk register and fallback scope

Domain lenses

Developer workflow

• repo or workflow boundary
• ownership between implementation, verification, docs, and release chores
• external tooling / access blockers

Web / fullstack

• frontend, backend, data, analytics, QA, rollout, docs
• auth or migration implications
• user-flow checkpoints

Product / operations

• approvals and decision checkpoints
• source-of-truth artifact updates
• reporting or enablement work
• handoffs between PM, ops, and delivery teams

Marketing / GTM

• asset creation
• review / approval
• channel setup and distribution
• measurement / attribution / reporting
• launch window timing

Game development

• systems/code
• content/art/UI/narrative/polish
• build/platform constraints
• QA/playtest/telemetry
• milestone/demo/readiness gates

Output discipline

• Keep one packet small enough to act on immediately.
• If you need multiple packets, name why: separate release packet, milestone packet, or discovery packet.
• Do not fold estimation, board control, or review workflow into the packet unless the user explicitly wants those adjacent tasks too.

Planning Patterns

Core idea

A useful planning packet converts ambiguous intent into slices that are small enough to commit, clear enough to review, and structured enough to estimate later.

Common planning horizons

• Single task — one bounded implementation or ops action
• Feature slice — a user-facing or system-facing increment with a clear outcome
• Sprint candidate — a set of ready slices small enough to consider in the next iteration
• Release slice — work grouped around a near-term release or campaign outcome
• Milestone plan — cross-discipline slices tied to a game, launch, or deadline milestone
• Backlog cleanup — reshaping, deduping, or clarifying work before commitment

Repeated failure modes

1. Oversized stories — one ticket hides multiple systems or owners 2. Readiness theater — tasks appear ready but still miss critical inputs 3. Discovery leakage — unknowns are buried inside implementation tickets 4. Silent blockers — approvals, assets, or external dependencies are omitted from the plan 5. One-board illusion — the tracker is official, but the real plan lives elsewhere

Decomposition lenses

When shaping work, choose the lens that matches the domain:

Software / web

• frontend
• backend
• data / migration
• QA / analytics / docs
• rollout / monitoring

Product / operations

• decision needed
• owner / approver
• process change
• artifact or report update
• training / enablement / audit trail

Marketing / GTM

• messaging
• creative asset production
• review / approval
• channel setup
• distribution and measurement

Game development

• game systems / code
• content / level / narrative / UI
• build and platform work
• QA / playtest / telemetry
• milestone or demo readiness

Planning sequence that transfers well

1. Clarify the goal 2. Split discovery from delivery 3. Identify the smallest meaningful slices 4. Attach dependencies and acceptance criteria 5. Separate ready from not-ready work 6. Return one recommended next move

Readiness Checklist

Use this checklist before treating a slice as ready for estimation or commitment.

Minimum readiness fields

• Problem or goal is stated clearly
• Outcome is specific enough to review
• Owner role is implied or known
• Dependencies are named
• Required inputs or missing artifacts are listed
• Acceptance criteria exist
• Major risk or uncertainty is called out

Ready vs not-ready

Usually ready

• The slice has one obvious owner role
• The outcome can be demonstrated or reviewed
• Missing decisions are minor, not structural
• Dependencies are known and manageable

Usually not ready

• The task hides multiple systems, disciplines, or owners
• Acceptance criteria are generic or missing
• The work depends on a decision nobody has made yet
• The team does not have the necessary assets, access, or environment
• Discovery and implementation are bundled together

Good blocker language

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

Domain reminders

Software

Check auth, data migration, rollout, analytics, and QA implications.

Product / ops

Check approval flow, reporting obligations, and source-of-truth artifacts.

Marketing

Check asset review timing, launch window, and measurement setup.

Game development

Check milestone intent, platform constraints, playtest criteria, content dependencies, and build-readiness needs.