Scoping a Dispatchable Task

The Document That Makes Parallelism Work

Everything about parallel dispatch — the worktrees, the fan-out patterns, the convergence flow — assumes that each worker knows exactly what to do, what not to do, and how to verify that the work is done.

That assumption is made true by the dispatch prompt.

The Five Fields Every Dispatch Prompt Must Answer

Scope: What exactly needs to happen? Name the specific actions, not the outcome. "Add export for PadWorktreeIsolationModel to components/mdx/index.ts" is a scope. "Update the registry" is not.

Definition of Done: What state will the system be in when the task is complete? For code tasks, this is always a test suite result and a tsc output. "npm run test passes. npx tsc --noEmit returns 0 errors." Anything subjective ("it works correctly") is not a definition of done.

Files in scope: Name the exact files the worker is allowed to touch. This prevents scope creep and makes the worker's diff predictable at convergence time.

Files off limits: Name the shared registry files explicitly. components/mdx/index.ts, lib/tracks.ts, lib/tiers.ts, tests/content-integrity.test.ts — these are never in a worker's scope. The orchestrator edits them last, once, after all workers finish.

Verification: The exact command to run, with expected output. "Run npm run test and paste the final line. Report PASS or FAIL." Not "make sure it works." The verification command produces evidence that the orchestrator can use to decide whether the worker's output is ready for convergence.

The Canonical Contract Line

Knox's dispatch prompts always end with the same structure:

Fix [N specific issues] in [specific files only].
Do NOT touch [off-limits files].
Run [verification command] and paste the output.
Report PASS (with output) or FAIL (with error text).
Do not report status without running the command.

The last line is the most important: "Do not report status without running the command." Agents are optimistic. Without this constraint, a worker will report "done" based on its belief that the code is correct, not based on evidence. The test output is the evidence.

Applying the Five Fields: Real Example

Knox is dispatching a parallel build session for this academy track. Here is a real dispatch prompt for the MDX lesson worker:

Write lesson-413-why-parallelize-the-agent-fleet-mindset.mdx and lesson-414-the-orchestrator-lead-worker-hierarchy.mdx in content/academy/.

Files in scope: content/academy/lesson-413-*.mdx, content/academy/lesson-414-*.mdx

Do NOT touch: components/mdx/index.ts, lib/tracks.ts, lib/tiers.ts, __tests__/content-integrity.test.ts

Each lesson must have:
- Valid frontmatter (title, date, category, lesson, track, excerpt, readTime, tags, status, quiz with 3+ questions)
- 800-2200 words of prose
- At least 2 bespoke diagram component imports
- 1 Callout variant="doctrine"
- At least 1 PowerWord

After writing both files, run: npx tsc --noEmit
Report the exact output. If 0 errors, report PASS. If errors, report FAIL with the full error text.

This prompt is dispatchable. Every one of the five fields is answered. The worker does not need to ask: "Which files should I create? What format should they use? Can I edit tracks.ts? How do I know when I'm done?"

Scope Creep and the "Helpful" Worker

The most common failure mode in worker tasks is helpful scope creep. A worker is assigned to write two lesson MDX files. While writing them, it notices that index.ts is missing the exports for the diagrams it referenced. So it adds them. Helpfully.

Now two things have happened:

1. The worker produced valid lesson files (good)
2. The worker edited index.ts (problem)

When a second worker also edits index.ts, the orchestrator faces a conflict at convergence. The helpful edit broke the isolation boundary.

The off-limits list prevents this. "Do NOT touch components/mdx/index.ts" is not distrust — it is a structural boundary that makes convergence predictable.

What a Good Dispatch Session Looks Like

Before Knox dispatches a batch of workers, he writes all the dispatch prompts. Not simultaneously — sequentially, carefully. Each prompt takes 5-10 minutes. A batch of 5 prompts takes 30-40 minutes to write well.

That 30-40 minutes is the highest-leverage activity in the entire dispatch session. It determines whether the next 2 hours of parallel execution produces clean, convergeable outputs or requires re-dispatch, debugging, and conflict resolution.

The prompt is harder to write than the code. It is more valuable than the code. Write it first.

What's Next

The next lesson covers git worktrees — the mechanical foundation for same-repo parallel dispatch. Worktrees are what prevent file edits from one worker overwriting another's work. Without them, even perfectly scoped dispatch prompts produce collisions.