luna-orchestrator

name	luna-orchestrator
description	Use visible GPT-5.6 Luna Max Codex tasks for two or more already-independent implementation tracks while one Sol task owns the outcome and integration. Use when the user explicitly asks for orchestration or the requested outcome already contains concurrent non-overlapping tracks.

Visible Luna task orchestration

Load and follow $outcome-driven-delivery before dispatch. This skill chooses the execution shape only; it never changes that skill's one-request, one-delivery, one-pull-request, single-check, review, approval, stopping, or packet rules.

Keep GPT-5.6 Sol accountable for the requested outcome, scope, dependencies, approvals, and final integration. Orchestrate only when the user asks or when at least two implementation tracks already exist and can run concurrently without waiting for each other's unfinished files. Do not split work to manufacture that condition. Otherwise, Sol implements directly.

When orchestration applies and the active Codex surface can create visible tasks:

1. Run the installed codex-multiprovider doctor and require desktop_version_coherence and desktop_runtime to be green before dispatch or acceptance. If the application updated beneath the running process, stop and require a clean full quit and relaunch at a chosen moment.
2. Resolve the destination from the app-native project list. Repository work uses the saved project whose root is that repository; never route it through an unrelated project just to obtain a host. Use projectless creation only for genuinely projectless work.
3. Use local only for explicitly shared, read-only, or non-overlapping work in the current checkout. Otherwise use an app-managed worktree from the saved project and the requested or verified ref. Do not pass startingState: working-tree unless the user explicitly asked to carry that exact dirty state; a dirty primary is never an implicit starting point.
4. Create one visible task per non-overlapping track using gpt-5.6-luna at max reasoning effort.
5. Give each task an exact outcome, workspace or worktree, owned files or subsystem, relevant constraints, one direct check, and a stop line.
6. Treat a returned clientThreadId as pending worktree setup, never as a created worker. Wait for a real threadId before assigning ownership or claiming dispatch. A setup error, unresolved client identifier, or model/effort validation error is a failed visible creation; do not retry through another project or a hidden worker. Sol implements that track.
7. Keep all workers inside the same user request, delivery, and pull request. Workers do not create durable outcomes, milestones, reviews, or pull requests.
8. Follow task progress without a long recursive wait. The signed app-server has hardcoded 10-second shutdown bounds, so no app-native wait may block for 8 seconds or longer. Use an immediate task snapshot (timeoutMs: 0) or one bounded sub-8-second wait between useful integration work; yield before polling again. Never wrap an app-native wait in a generic tool runner: a yielded runner cell can outlive a recycled app-server and leave a stale continuation. Do not continuously poll; intervene only for scope drift, a dependency handoff, an approval or blocker, or final integration.
9. After terminal handback, Sol inspects the exact diff and direct check, resolves integration conflicts, and owns the final result.

Resolve Luna availability only from the app-native visible create_thread model catalog on the destination host. The hidden spawn_agent or collaboration model list is a different surface and is never evidence that visible Luna is unavailable. If gpt-5.6-luna is listed, create the visible task with that exact model and max effort. Treat Luna as unavailable only when it is absent from that app-native catalog or an actual visible Luna creation call fails.

Do not use detached workers, raw codex exec, hidden implementation subagents, continuous polling, supervision agents, goal-continuation tools, or extra reviews to recreate this pattern. Hidden subagents remain suitable only for short read-only research or an explicitly requested review; they never substitute for a requested Luna implementation track. If an app-native visible Luna task is actually unavailable or its creation fails, Sol implements directly.

Task creation never expands filesystem, provider, credential, approval, GitHub, or external-action authority. A worker stops at the same authority boundary as the orchestrator.