---
name: project-plan-builder
description: Build a project plan with a work breakdown, milestones, dependencies, and owners from a described goal. Use this skill whenever a user needs to plan a project, break down work, create a timeline or roadmap, or says 'plan this project', 'break this into tasks', or 'we need a roadmap for this'. Trigger whenever a goal needs to become a structured, sequenced plan of work someone can execute against.
---

# Project Plan Builder

## What this does and why it matters
Ambitious goals stall when they stay abstract. This skill decomposes a goal into a structured work breakdown with phases, milestones, dependencies, owners, and realistic sequencing, so a team can actually start Monday and know what "done" means at each step. A good plan surfaces the risks and dependencies before they become fire drills.

## Inputs to gather
1. The goal and the definition of done.
2. The deadline or timeframe, if any.
3. The people or roles available and their capacity.
4. Known constraints, dependencies, and risks.

## Method

### 1. Clarify the outcome and success criteria
State what the project delivers and how success is measured, so the plan serves the goal rather than activity for its own sake.

### 2. Break work into phases and tasks
Decompose into logical phases, then into tasks small enough to estimate and own. A task that cannot be estimated is too big and should be split.

### 3. Sequence and expose dependencies
Order the work and flag what blocks what. The critical path (the chain that determines the finish date) should be explicit, since that is where slippage hurts most.

### 4. Assign owners and rough estimates
Every task gets a single owner and a rough effort or duration. Shared ownership is no ownership.

### 5. Set milestones
Meaningful checkpoints that mark real progress, not just calendar dates.

### 6. Surface risks and buffer
Name the top risks with a mitigation each, and build buffer where uncertainty is highest, so the plan survives contact with reality.

## Output format
ALWAYS use:

# Project Plan: [Project Name]
## Goal and success criteria
## Phases and tasks (task | owner | estimate | dependencies)
## Milestones (with target timing)
## Critical path (the chain that sets the finish date)
## Risks and mitigations
## Assumptions and open questions

## Anti-patterns to avoid
- Tasks too vague or too large to estimate or own.
- No dependencies mapped, so blockers surprise the team.
- Shared ownership with no single accountable person.
- A plan with no buffer that assumes everything goes right.

## Example
For a website relaunch, the plan splits into discovery, build, content, and launch phases, flags content as the critical path, assigns each task an owner, and buffers the content phase where the most uncertainty lives.
