01 / START HERE
A useful way to approach it.
'Work on the launch' is too broad to assign. 'Draft the invitation using the approved venue details' names an action, an output, and a dependency. A useful task list makes the next step easy to recognize and gives the team a way to tell when the work is ready for review.
Use o1 to break an agreed project outline into a draft table. Supply constraints and real ownership decisions where you have them. The guide's examples are authored text, not tasks created in a workspace. Keep assignment, calendar dates, and project-board updates as separate actions you confirm through your normal process.
02 / THE PROCESS
Go from question to next step.
- 01
Start from agreed outputs
List the deliverables the project is meant to produce and any acceptance conditions. Keep unresolved scope outside the confirmed task list. Breaking an ambiguous goal into smaller activities does not resolve its meaning. If the expected output is unclear, return to the scope question before estimating the steps.
- 02
Break work into manageable actions
Use a verb and an observable result for each task. Split a task when it contains different outputs, owners, or important dependencies. Avoid splitting so finely that routine actions obscure the project. The useful size is one a responsible person can understand, complete, and hand over for the next step.
- 03
Map dependencies and blockers
Ask what each task needs before it can start and what its output enables. Identify assets, decisions, access, or prior work that can block progress. Keep a blocked task visible with its blocker rather than assigning an arbitrary due date. Review whether any proposed dependency is truly required or just a preferred sequence.
- 04
Define ownership and milestones
Record confirmed owners where available and use role placeholders for unassigned work. Choose milestones that mark an approved output or a decision, such as a confirmed venue or an accepted draft. A date passing is not evidence that a milestone was achieved. Explain what a reviewer should inspect at each checkpoint.
- 05
Review capacity and transfer deliberately
Check the draft against actual availability and commitments. Ask the people doing the work to confirm ownership and realistic sequence. Transfer the reviewed tasks into your chosen system only after that decision. Keep estimated effort separate from calendar duration, and update the table when a dependency changes instead of silently preserving an obsolete schedule.
03 / YOUR STARTING POINT
A prompt you can make your own.
Replace the bracketed fields. Add only information you have permission to share. This is a reusable text prompt; it does not run a task from this page.
Break this agreed project outline into a task-and-milestone draft: {{project}}. Deliverables and acceptance criteria: {{outputs}}. Constraints and confirmed owners: {{constraints}}. For each task show action, output, dependency, owner or 'unassigned', and review condition. Separate milestones from ordinary tasks and explain the evidence needed to pass each milestone. Flag missing steps, blockers, and assumptions. Do not invent agreed dates or assignments, and do not claim any project-board entries were created. Finish with what the team should confirm before transfer.04 / SEE THE SHAPE OF IT
Illustrative community-event task breakdown
Fictional project and authored task draft; no people have accepted assignments and no tasks were created in a system.
| Task / milestone | Output | Dependency / ownership |
|---|---|---|
| Compare two venues | A requirements comparison | Needs attendance estimate; owner unassigned |
| Venue decision milestone | Confirmed venue choice | Requires reviewed comparison |
| Draft invitation | Text ready for review | Needs confirmed venue details |
| Invitation approval milestone | Approved factual copy | Requires designated reviewer |
The milestone marks a decision that unlocks later work. It does not become complete simply because a proposed date has arrived.
05 / KEEP YOUR JUDGMENT
What to watch before you use it.
Assigning vague activities
A task needs an output and a way to recognize completion. Replace broad labels with a specific action and result.
Ignoring the blocker
A task waiting for content or approval cannot be scheduled like an independent action. Show what needs to happen first.
Making every task a milestone
Reserve milestones for meaningful outputs or decisions. Too many checkpoints make the important approvals harder to see.
06 / THE FINAL PASS
A little review goes a long way.
Your checks stay on this page. They do not approve or run a task.
07 / GOOD QUESTIONS
Before you begin.
How small should a task be?
Small enough that one owner can understand its result and prerequisites, but large enough to avoid clutter. Split work when the output, responsibility, or dependency changes. There is no universal duration that makes every task useful.
Can an assistant estimate project duration?
It can propose assumptions and a sequence from the information you provide. You need to check actual capacity, dependencies, and external commitments. Treat sample estimates as provisional rather than evidence that a team accepted the schedule.
What makes a milestone different from a task?
A task is work somebody performs. A milestone marks a significant state or decision, such as approved content or a confirmed venue. Define the evidence needed to reach it and identify who reviews that evidence.