Task Planning

By the Syncfusion DevTutorials team · Last updated October 21, 2026

Break a feature into agent-sized tasks in plan.md, with the files each task touches and what it waits for. Land the contract first, so parallel agents never collide.

Three Agents, One File

Some AI tools can run several agents at the same time.

This can save time. But only if the work is planned well.

Things go wrong when:

• two agents change the same file at the same time;
• an agent starts before the work it needs is ready.

In this lesson, three agents start together. Two of them change the same file. None of them waits for the others.

Simple lesson: running agents side by side needs a plan.

A Real-World Example

Four friends cook dinner together.

They all start at once. Two of them grab the same pan. One starts cooking before anyone picks the menu.

A better way:

• One friend picks the menu first.
• Then everyone starts.
• Each friend uses their own pan.

AI agents need the same kind of plan.

Press Run it and open the Agent tab.

• CONFLICT lines show two tasks changing the same file.
• Some tasks start before the shared types exist.

Then open Preview & Checks to see which tasks ran side by side.

Simple lesson: each file needs one owner, and some tasks must wait.

TL;DR

1. plan.md = the third file, after intent.md and spec.md.
2. A plan is a list of tasks.

3. Each task line has:

   • an ID, like T1;
   • a short title;
   • the files it changes;
   • the tasks it waits for.
4. Wave = a group of tasks that run at the same time.
5. Two tasks in the same wave must not change the same file.
6. The contract task goes first, on its own.
7. Every task that uses the contract waits for it.
8. Keep each task small: three files or fewer.

What You Will Learn

In this lesson, you will learn:

1. What plan.md is.
2. How to write a task line.
3. How tasks run in waves.
4. Why the contract task comes first.
5. How to keep tasks small.

What plan.md Is

The Third File

Each file answers a different question:

• intent.md = why we build it.
• spec.md = what we build.
• plan.md = who does each part, and in what order.

A task line looks like this:

- T2: Build exportOrders (files: src/features/export/exportOrders.ts) (after: T1)

It has four parts:

• ID: T2
• Title: Build exportOrders
• Files: the files this task changes
• After: the tasks it must wait for

If a task does not list its files, nobody can see a conflict coming.

A Task Graph

Task graph = a picture of which task waits for which.

Example:

T1 → T2
T1 → T3
T2 → T4

This means:

• T2 waits for T1.
• T3 waits for T1.
• T4 waits for T2.

A task graph must never go in a circle.

Example of a circle:

T1 waits for T4
T4 waits for T2
T2 waits for T1

Every task waits for another one. So no task can ever start.

Simple lesson: a task can only wait for work that comes before it.

Waves

Who Runs at the Same Time

Wave = a group of tasks that start together.

A task joins a wave as soon as everything it waits for is done.

Watch the agents run the plan, one wave at a time.

Only T1 runs first. The other three start together once T1 is done.

Collisions

Collision = two tasks in the same wave change the same file.

Example:

T1 → types.ts
T3 → types.ts

Both agents change types.ts at the same time.

This can lead to:

• a merge conflict;
• one agent's work being lost;
• two versions that do not fit together.

One rule stops this:

One file, one owner per wave.

If two tasks need the same file, one task owns it. The other task waits for it.

Watch the conflicts disappear as the plan gets better.

First the tasks collide. Then the contract gets its own task. Finally every task waits for it, and the conflicts are gone.

The Contract Lands First

Why First

You learned about contracts in the API Contracts lesson.

Contract = the shared names and types every task builds on.

These tasks all need the contract:

• the code that does the export;
• the tests;
• the button or route that calls it.

If they start before the contract exists, each agent invents its own version. The pieces will not fit together.

So the contract task runs first, on its own.

Every other task adds this to its line:

(after: T1)

Agent-Sized Tasks

Agent-sized task = a task one agent can finish and check on its own.

In this course, that means three files or fewer.

Small tasks are easier to:

• review;
• test;
• run again;
• fix.

A big task can hide many problems in one place.

Watch one big task get split into small ones.

One big task fails the size check. Four small tasks pass every check.

Simple lesson: small tasks fail small, so you can find the problem.

Lab Exercise: Plan So the Contract Lands First

Rewrite plan.md.

Your plan must:

• have one task for each piece of work;
• put the contract task first;
• make every other task wait for the contract;
• give each file only one task;
• keep each task small.

Press Check my spec.

A correct plan:

• has zero conflicts;
• runs the contract task first;
• lets the other tasks run side by side safely.

What Changes per Tool

The tools are different. The rules stay the same:

• the contract comes first;
• each file has one owner;
• each task says what it waits for;
• no two tasks change the same file at once.

Common Mistakes

Exercises

These exercises help you practise writing a plan.

Press Check when you are ready. Use Show Hint if you get stuck.

What to Remember

• plan.md says who does each part, and in what order.
• Each task lists its ID, its files and what it waits for.
• Tasks run in waves.
• Two tasks in one wave must not change the same file.
• The contract task comes first, on its own.
• Every task that uses the contract waits for it.
• Small tasks are easier to finish, test and fix.

Further Reading

• Effective harnesses for long-running agents, by Anthropic: feature lists and progress files as handoffs.
• GitHub Spec Kit: plan and tasks in a Spec Kit feature.
• Kiro specs: tasks that link back to requirements.

Next: Subagent Briefs. You will learn how to hand one task to a helper agent, and get back a result you can use.