The task is the prompt: writing tasks agents can finish

In Dispatcher, a task is not a ticket that someone later translates into a prompt. The task is the prompt. When you execute it, its title, description, and attached context are what the agent starts from.

That changes how you should write them. A task written for a teammate can lean on shared memory and a hallway conversation. A task written for an agent has to stand on its own.

The five parts of a task an agent can finish

1. The outcome, in one sentence. Start with what will be true when this is done, not with the steps. "Users can export billing history as CSV from the billing settings page."

2. The scope. Name where the change lives and, just as important, where it does not. "Changes are limited to src/billing/. Do not modify the invoices API."

3. Constraints. The things the agent cannot infer: keep existing routes stable, match the existing table component, no new dependencies.

4. Context. Link the spec, the design note, or the earlier discussion instead of paraphrasing it. In Dispatcher, attached knowledge documents are synced into the worktree so the agent can read the original.

5. A definition of done. Make it checkable: which tests must pass, which command must succeed, which screen must show what.

An example

Before:

CSV export for billing

After:

Add CSV export to billing history. Users can download their billing history as a CSV from Settings, then Billing. Scope: src/billing/ and its tests. Do not change the invoices API. Constraints: reuse the existing DataTable toolbar for the button; no new dependencies. Context: see "Billing export spec" in the knowledge base. Done when: npm test -- billing passes and the exported file opens in a spreadsheet with one row per invoice.

The second version takes two minutes longer to write. It routinely saves a full review-and-retry cycle.

Smaller is better

Agents degrade on long, loosely connected tasks the same way people do. If a task has an "and also," it is usually two tasks. Small tasks also make for small diffs, and small diffs are the ones that get reviewed properly.

When a change genuinely is large, keep it in one task but plan to ship it as a stack of pull requests, each one reviewable on its own.

Let the board be the queue

Once tasks are written this way, the board becomes a queue you can hand to agents in parallel. The backlog stops being a list of reminders and becomes work that is ready to start. Whether the next one is picked up by Claude Code, Codex, or a teammate, it starts from the same clear description.