---
name: task-planning
description: Use when work has multiple steps, unclear requirements, meaningful risk, or several possible approaches and execution should wait for explicit confirmation.
---

# Task Planning

Plan before acting. Restate the goal, define success, surface tradeoffs, identify risks, and wait for explicit approval before executing.

## When to Use

- Starting a new project or initiative
- Work that involves multiple steps or people
- Requirements are unclear or ambiguous
- Multiple approaches are possible
- High stakes (presentation, launch, campaign, report)
- You need a lightweight plan, not a full implementation spec

## The Process

1. **Restate Requirements** - Clarify what needs to be accomplished in your own words.
2. **State Assumptions** - Name defaults you are choosing and uncertainties that remain.
3. **Define Success Criteria** - What proves this is done? Include verification method.
4. **Compare Approaches** - For meaningful choices, present 2-3 options with tradeoffs and a recommendation.
5. **Break Down into Phases** - Specific, actionable steps in logical order.
6. **Identify Dependencies** - What needs to happen before what.
7. **Assess Risks** - What could go wrong, how likely it is, and the fallback.
8. **Present the Plan** - WAIT for explicit confirmation before proceeding.

## Environment Orientation

Before proposing concrete commands, paths, or owners, check the relevant environment:

- Current working directory and target repo/project
- Existing local instructions (`CLAUDE.md`, `AGENTS.md`, `.agents/skills/`)
- Tool availability and authentication if external systems are involved
- Git branch/worktree state if edits are expected

Do not assume the visible directory, first connector, or default branch is the right target.

## Plan Format

```markdown
# Plan: [Project Name]

## Goal
[One sentence: what does success look like?]

## Assumptions
- [Assumption and why it is reasonable]

## Success Criteria
- [Concrete check, command, review, or observable result]

## Approach
- Recommended: [Approach]
- Alternative considered: [Approach + tradeoff]

## Phases

### Phase 1: [Name]
- Step 1: ...
- Step 2: ...
- Deliverable: ...

### Phase 2: [Name]
- Step 1: ...
- Step 2: ...
- Deliverable: ...

## Dependencies
- Phase 2 requires Phase 1 deliverable
- [External dependency: waiting on X from Y]

## Risks
- HIGH: [What could block us entirely] -> [fallback]
- MEDIUM: [What could slow us down] -> [mitigation]
- LOW: [Minor inconvenience] -> [watch item]

## Verification
- [How we will prove each phase or final output is correct]

## Open Questions
- [Only questions that block safe execution]

## WAITING FOR CONFIRMATION: Proceed with this plan?
```

## Example

```
User: I need to plan our product launch event next month

Claude:
# Plan: Product Launch Event

## Goal
Execute a successful product launch event that generates media coverage and customer interest.

## Phases

### Phase 1: Foundation (Week 1)
- Define target audience and key message
- Set budget and venue requirements
- Create guest list (media, VIPs, customers)
- Deliverable: Event brief document

### Phase 2: Logistics (Week 2)
- Book venue and catering
- Design invitations and send out
- Arrange AV equipment and stage setup
- Deliverable: Confirmed bookings and sent invitations

### Phase 3: Content (Week 3)
- Write keynote script and talking points
- Prepare demo and product materials
- Create press kit and media briefing
- Deliverable: All presentation materials ready

### Phase 4: Execution (Week 4)
- Rehearsal and dry run
- Day-of coordination
- Post-event follow-up (thank you notes, press coverage tracking)
- Deliverable: Successful event + follow-up complete

## Risks
- HIGH: Venue cancellation (backup venue needed)
- MEDIUM: Low RSVP rate (prepare follow-up outreach)
- LOW: AV issues (bring backup laptop + adapters)

WAITING FOR CONFIRMATION: Proceed with this plan?
```

## Important

- **NEVER start executing without confirmation**
- If the user wants changes, revise the plan first
- Keep phases small enough to review progress between them
- Flag risks early, don't surprise later
- Do not hide uncertainty. If a plan depends on an assumption, write it down.
- If the plan is for coding work, hand off to `writing-action-plans` after approval.