Delegation mode makes the filesystem the source of truth for delegated work. The chat transcript is useful for progress updates, but it is never the only handoff. A coordinator creates an executable plan, each worker writes its own result directly to , and a later session reruns the same plan with completed task IDs skipped. The reusable runner validates the result file, not just the worker's response, before it confirms a task.

Use this mode for work that is large, multi-step, parallelizable, likely to outlive one context window, or valuable as a durable plan for the next agent. Do not use it for a small interactive answer that has no durable output.

Use one plan script per run:

.agents/plans/
├── YYYY-MM-DD-<slug>.js              # executable dispatcher and resume state
├── YYYY-MM-DD-<slug>-<task-id>.md    # one durable result per task
└── YYYY-MM-DD-<slug>-FINAL.md        # optional aggregation plan

Copy to the first path and fill in the project context and task definitions. The script must contain:

Keep the plan script in so another session can execute the same file without reconstructing the dispatch logic from chat. Fill in every placeholder before running it. The plan's , , task IDs, and output paths are part of its identity; create a new slug when the scope changes.

The reusable template loads , which is the single source for plan identity checks, safe output paths, , Markdown frontmatter, completion markers, and durable-file validation. The loader checks the publishable source tree and installed skill tree so a copied plan remains usable after installation.

Every delegated worker must:

For implementation tasks, the result plan should record what changed, files affected, verification performed, remaining risks, and the next action. For analysis tasks, it should record scope, evidence, conclusions, and recommended work. Empty results are valid when the worker explicitly records that it checked the scope and found nothing.

The default is sequential:

const MODE = "sequential";

The runner awaits each pending task before dispatching the next. Use it when:

Use parallel only when all pending tasks are independent:

const MODE = "parallel";

Parallel tasks must be read-only with respect to application source, write different output files, and not depend on another task's result. The runner uses , so one failed worker does not hide results from the others. Aggregation is blocked until every task has a validated result file. If a task declares , it must run after those task IDs are confirmed; parallel mode is valid only when the dependency graph permits independent dispatch.

Every writable delegated task uses:

config: { $kind: "general" }

Do not use an explore-only worker for a task whose completion requires writing a file. Use specialized worker kinds only when the composition skill explicitly defines a compatible file-writing contract.

A killed Code Execution run does not invalidate files already written by workers. Resume from the plan, not from the transcript:

Do not infer completion from a worker's silence, a partial file, or an old chat message. If a result file exists but its completion marker or required content is missing, leave the ID out of and rerun that task. If the review scope changes, create a new slug instead of reusing old results.

is intentionally explicit rather than inferred by an in-script filesystem scan. This makes the resume decision auditable and prevents a truncated or stale file from being treated as complete.

Delegation mode is an execution layer, not a review methodology. A larger skill can define its own task list and result schema while using this contract. For example, :

For hard tasks, decompose the work into tasks with explicit dependencies, select sequential mode where needed, and make the final task read the earlier plan files instead of depending on chat context.

The result file is the durable record. Use these meanings in its frontmatter or body:

pending

running

blocked

done

Never mark a task merely because most of it is complete. A plan script should report unresolved tasks and skip final aggregation when any task throws or lacks its marker.

Before reporting a delegated run complete:

Do not claim approval while unresolved critical blockers remain.