Delegate ONE bounded implementation task to an isolated gpt-5.6-luna worker thread.

Use this when a task is well-specified enough to hand off: you can state the objective, what "done" looks like, and which files may change. Keep architecture, sequencing, and final judgement for yourself.

Choosing effort — rate THIS TASK's intrinsic difficulty, never the parent project's importance: medium Mechanical and fully specified. Rename, move, boilerplate, obvious test cases, applying a pattern that already exists in the codebase. high DEFAULT. Real implementation work needing judgement within one area: a new endpoint, a bug fix with a known repro, a focused refactor. xhigh Subtle or cross-cutting. Concurrency, tricky state, non-obvious performance work, changes rippling across several modules, or a bug whose cause is not yet identified. max Genuinely hard problems only. Reserve for tasks where a strong engineer would expect to be stuck for a while: intricate algorithms, deep debugging with no clear lead, or a task that already came back FAILED at xhigh. An important task that is straightforward is still "high" — importance is not difficulty.

Prefer escalating over starting high: run at high, and if it comes back FAILED because the task was genuinely hard, re-delegate at xhigh with previousAttempts filled in. If it failed because your brief was vague, fix the brief instead — the same objective at higher effort usually fails again, slower.

BEFORE delegating at all, decide whether it is worth it. Delegation has a fixed overhead — writing the contract, spawning a thread, re-verifying the result — and on small work that overhead exceeds the work itself. Measured on this project's own micro-benchmark, delegating a one-file task was ~2.3x slower and ~3.5x the tokens of just doing it, with no quality difference.

Do it yourself when:

• the change is small, mechanical, or confined to one file

• you already know the exact edit

• explaining the task would take longer than making the change

• there is no second independent piece of work to overlap it with

Delegate a single task when the work is substantial and bounded, and you want an enforced file scope plus independently re-run verification.

For two or more independent pieces of work, use delegate_tasks instead — that is where delegation can actually save wall-clock time.

The worker cannot delegate further and cannot see this conversation.

The result is evidence, not a conclusion. The orchestrator independently re-runs your verificationCommands after the worker exits and checks which files were actually touched, then returns verdict, discrepancies, and reviewChecklist. A worker PASS with a FAILED verdict means the worker was wrong. Always review the diff before accepting.

verificationCommands run without a shell: one allowlisted executable per command, no pipes, redirects, && or ;. Use npm test or pytest -q, not npm run build && npm test (pass those as two commands).

Delegate SEVERAL bounded tasks to gpt-5.6-luna workers, in parallel or in sequence.

This is where delegation can actually pay for itself. A single small task is faster done yourself; several substantial, independent tasks are not.

Pick the mode deliberately:

parallel Two or more tasks that do NOT depend on each other. Each worker gets its own git worktree branched from HEAD, so they cannot see or clobber each other. Afterwards their changes are integrated only if no two workers touched the same file. Requires: a git repository with at least one commit, and no uncommitted changes inside the declared task scopes.

sequential Tasks that build on each other, or that must touch the same files. They share the workspace and run one at a time, so a later task sees the earlier one's work. No git requirement.

Give every parallel task a DISJOINT allowedFiles scope — e.g. src/auth/** and src/payments/**, never src/auth/** and src/**. Overlapping scopes are rejected up front, because the outcome would depend on which worker finished last. Choose sequential mode instead when the work genuinely shares files.

Each task carries its own effort. Rate each task separately: a batch may mix medium, high and xhigh workers, and usually should.

Do NOT use this to fan out work that is really one task, and do not split a change so finely that coordinating the pieces costs more than writing them.

Partial failure is normal and is reported, not hidden: successful tasks are kept and you decide per task whether to retry, re-scope, or accept. Nothing is merged automatically when workers collide.