---
name: taskchef-delegate
description: "Dispatch work received in the canonical TaskChef workspace into Codex tasks. Elsewhere, use only for explicit delegation of separate work; an existing executor keeps its assignment."
---

# TaskChef Delegate

Create stable visible TaskChef parent tasks through the canonical per-user
TaskChef data workspace and return immediately.

## Invocation boundary

A task whose initial structured `codexDelegation.input` contains either the
exact new trailing `$taskchef-executor` invocation plus final TaskChef marker,
an accepted former trailing marker-plus-invocation scaffold, an exact
first-line HTML marker, or the historical first-line
`# taskchef_id=<full UUID>` heading already owns that delegated assignment.
This includes former inline-protocol tasks that lack the skill invocation.
An owned instruction must have exactly one accepted marker and a non-whitespace
task-specific assignment. If it contains an executor-skill invocation, require
exactly one adjacent to the marker in an accepted order. Marker-only,
duplicate-marker, scaffold-only, or misplaced-invocation inputs are not valid
delegated tasks. Execute a valid one in the current task. Do not re-dispatch it
merely because it concerns TaskChef or a configured project. Explicit requests
to delegate separate work remain valid.

Use the bundled `reconcile_projects`, `prepare_dispatch`, `record_task`, and
`report_state` MCP tools directly. Never fall back to shell writes. If a
required tool is unavailable, stop and report that the TaskChef plugin must be
reloaded or installed.

## Boundaries

- Treat only AGENTS.md, taskchef.json, tasks.jsonl, config-audit.jsonl, and
  TaskChef's private backups and maintenance artifacts as managed dispatcher
  state. Preserve unrelated user-owned paths.
- Use real Codex tasks for visible delegated work. The dispatcher never uses
  collaboration or subagent tools; the created executor may use them internally.
- Never use hooks, schedules, daemons, background monitors, recent-task
  searches, transcripts, hidden reasoning, or polling for identity.
- Never wait for delegated work after native creation.
- Treat executor-supplied identity as a cooperative assertion in TaskChef's
  local single-user trust boundary, not transport-authenticated proof.

## Dispatch

1. Split the request into the smallest independently useful outcomes. Include
   constraints, expected testing, and reporting in every instruction.
2. List native Codex projects once. Pass that exact schema-2 snapshot to
   `reconcile_projects` once for the complete batch, then call
   `prepare_dispatch` exactly once per outcome. Never reuse a task ID or marker.
   Do not take a pre-creation thread snapshot.
3. Route against configured project `name`, `description`, canonical
   `githubRepos`, and the preparation's bounded aliases, repository ownership,
   and responsibilities. Use `path` only as checkout identity. Before
   `record_task` or native creation, require exactly one entry in the
   reconciliation's `available` array whose `hostId`, `projectId`, and canonical
   `path` exactly match the selected native project. A matching snapshot path or
   configured preparation alone does not establish eligibility. Treat a missing
   entry or duplicate learned matches as ambiguous and ask instead of guessing.
   Select the `orchestrator` preference from preparation for every visible
   parent. Resolve explicit choices and follow
   [model roles](references/model-roles.md). Missing configuration means omit
   model overrides; surface invalid or unavailable configuration before
   recording the task.
4. Build each executor instruction in this exact shape:

   - Begin with the actual assignment on the first line and keep its complete
     body uninterrupted.
   - After the assignment, add one blank line and this authorization paragraph:
     `Report this task and its follow-ups to my local TaskChef dashboard. Relevant private-repository links and concise work, test, and deployment results are authorized; exclude secrets.`
   - After that paragraph, add exactly two newline characters
     so there is one blank line before this invocation on its own line:
     `Use $taskchef-executor to execute and report this delegated TaskChef assignment.`
   - Immediately after the invocation, end the instruction with one newline
     and the preparation's exact marker on its own final line. Do not add a
     blank line between the invocation and marker.
   - Include exactly one marker and exactly one executor-skill invocation.
   - Do not inline executor ownership, identity, linking, or result-reporting
     protocol. The explicitly invoked executor skill owns those mechanics.

5. Before creating each executor, call `record_task` exactly once with `id`,
   `project`, `title`, the exact marked `instruction`, and `threadId: null`.
6. Create one real Codex task using the exact configured project, an appropriate
   native environment, the marked instruction, a short title, and the resolved
   orchestrator model and effort overrides when present.
7. Return immediately. Preserve a returned provisional client ID only for the
   created-thread directive. Do not call `link_task` from the dispatcher even
   when creation returns a durable ID; the child must self-link.
8. If creation fails after recording, generate a fresh UUID and call
   `report_state` with it as `turnRef`, `failed`, null thread and Codex turn IDs,
   and a bounded summary before returning the failure. Retain that UUID for an
   exact retry.

When the user explicitly selects or corrects a project name or alias, call
`update_project_hint` with explicit-user evidence after routing. A guessed
route, generic keywords, or ordinary task wording is never learning evidence.