Redesign GPT-6 routing and proactive Luna fleet workflow

skills/codex-subagent-router/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: codex-subagent-router
-description: Decide when Codex subagents help, route bounded work across Astra, Sol, Terra and Luna, and manage child evidence and lifecycle. Use for delegation requests, routing decisions, or subagent audits; inspecting this skill does not itself authorize spawning.
+description: Route authorized Codex subagents across GPT-6 Luna, Sol and Astra; manage ownership, lifecycle and evidence. Use for delegation, routing decisions or subagent audits. Discovery alone does not authorize spawning.
 ---
 
 # Codex Subagent Router
@@ -11,8 +11,8 @@ Make delegation useful, observable and bounded. Preserve the selected parent mod
 
 Classify the request before using child tools:
 
-- **Audit or advice:** inspect rules, configuration and available tools; report findings without spawning or changing settings.
-- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it. Within that scope, actively delegate independent useful slices while the parent advances other work.
+- **Routing audit or advice only:** inspect rules, configuration and available tools; report findings without spawning or changing settings. Ordinary code review can use authorized read-only children under a standing parallel-work policy; it does not authorize edits.
+- **Authorized execution:** the user requested delegation, or an applicable instruction explicitly authorizes it, including an active standing parallel-work policy. Within that scope, proactively dispatch useful independent slices while the parent advances other work; do not wait for another invitation to use agents.
 - **No delegation authorization:** work locally. Automatic skill discovery, model availability, task complexity and a request to edit this skill do not grant permission to spawn.
 
 Honor higher-priority host restrictions even when a lower-priority rule permits delegation. Do not request authorization repeatedly after it has been granted. Never turn a routing recommendation into a new user-owned task.
@@ -23,22 +23,43 @@ Before dispatch classify each candidate:
 - **C:** a bounded investigation/draft that needs latest-baseline parent integration.
 - **S:** an immediate dependency, overlapping contract/state, permissions, production mutation, PR/merge/deploy or final acceptance; keep it in the parent.
 
-Spawn only P/C work with a concrete output and useful parent work available. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
+Spawn only P/C work with a concrete output and useful parallel benefit. Prefer useful parent work alongside children; when the host permits, multiple independent children may run while the parent waits to synthesize and accept their results. Honor any stricter host requirement for concurrent parent work. Do not spawn for one command, ceremonial probes, duplicate reviews or a model quota. Batch homogeneous small work.
+
+Choose the execution mechanism before a model: local tools for fixed commands/transforms, host-supported concurrent or async tools for independent I/O, and authorized children for useful independent reasoning or implementation. Waiting on a tool alone is not a reason to create an agent. Prefer a coherent outcome with acceptance over many tiny handoffs; bound ambiguity and ownership rather than prescribing every reasoning step.
+
+## Proactive Luna fleet
+
+Once authorized, parallel execution is the default for ready independent work. At the first useful decomposition and after each material result or scope change, look for slices that can run alongside the parent's critical path. Dispatch those slices promptly instead of finishing the parent's entire investigation first. Do not require proof of measured speedup before a clearly useful split.
+
+- Fan out bounded Luna assignments by independent evidence source, module, test suite or settled file/semantic ownership. Useful lanes include source inventory, artifact comparison, fixed validation, focused first-pass review and settled patches. Batch tiny homogeneous items into meaningful assignments.
+- Keep a small ready queue. Use as many actually available child slots as useful independent work and parent review capacity support; there is no fixed one-child or two-child ceiling. Reserve the parent when the host counts it. For example, four total active slots permit at most three concurrent children alongside the parent, not an unlimited fleet.
+- Refill available capacity when a result is handed back: accept/triage it, reuse an eligible idle child or dispatch the next ready slice. Do not wait for a whole wave if another independent slice is ready. Verify actual capacity; completed or interrupted does not necessarily mean released.
+- The parent owns contract decisions, cross-result synthesis and acceptance, and advances a parent-suitable critical-path slice when one is available. Integrate incrementally. If review backlog, conflicting ownership, I/O contention or rate limits becomes the bottleneck, reduce new dispatch and drain it.
+- One owner per file AND shared semantic contract. Parallel disjoint writes only when the host permits them; shared registries, integration and external gates remain serial. Read-only workers also need stable baselines and coordinated mutable sessions.
+- Choose Sol directly for slices requiring open-ended investigation or design, and Astra for the hardest synthesis. A fleet is a capacity strategy, not an instruction to force every task onto Luna or to duplicate the same review.
+
+Stay local for a trivial task, no useful parallel benefit, an immediate dependency with no independent work, or inadequate host support. State the relevant reason briefly when a requested parallel run cannot proceed; do not produce a routing report for every small task. Standing authorization does not authorize recursive unbounded fan-out, new user-owned tasks, configuration changes or external writes.
 
 ## Select a supported route explicitly
 
 | Work shape | Initial route |
 | --- | --- |
-| Known-source collection, fixed checks, logs | Luna low/medium |
-| Bounded classification, conversion, settled patch with fixed checks | Luna high |
-| Everyday implementation, debugging, locating/correlating artifacts | Terra medium; high when needed |
-| Bounded complex analysis, design or financial/security evidence | Sol medium; high when needed |
-| Hardest independent synthesis across code, tools and research | Astra medium; high when needed |
+| Known-source collection, fixed checks, logs | GPT-6 Luna low; medium for multi-step work |
+| Bounded classification, conversion, settled patch with fixed checks | GPT-6 Luna medium; high for local reasoning |
+| Everyday implementation, debugging, locating/correlating artifacts | GPT-6 Sol medium |
+| Bounded complex analysis, design or financial/security evidence | GPT-6 Sol medium/high |
+| Hardest independent synthesis across code, tools and research | GPT-6 Astra medium/high |
 | Shared decisions, integration and external/final gates | Current parent, serial |
 
-These are starting heuristics, not measured cost rankings. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, pause that slice and return the evidence to the parent.
+Luna is the first candidate when inputs are bounded, the contract is settled, correctness is cheaply checkable, and failure is contained. All four conditions matter; a short diff can still hide a shared semantic decision. Use Sol directly when investigation, design choices or cross-file causal reasoning dominate. Use Astra directly for the hardest independent synthesis when expected quality or saved rework justifies it. Do not make high/max Luna a mandatory step before Sol.
 
-Use the lowest adequate supported effort. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
+These are starting heuristics, not measured task-cost rankings. Lower prices broaden the useful Luna workload; fill supported capacity with useful work under existing authorization, never infer extra host slots from price. Pick sufficient capability directly; do not escalate through every model. Missing access/data and tool failures need diagnosis, not a stronger model. After two same-class failures, stop that slice and return the evidence to the parent; escalate earlier when the contract no longer fits. Preserve useful evidence on handoff instead of restarting discovery.
+
+Resolve exact IDs from the child-tool schema: prefer `gpt-6-luna`, `gpt-6-sol`, `gpt-6-astra` only when exposed. GPT-5.6 models are explicit compatibility routes, not aliases for GPT-6. For a legacy-only host use [routing boundaries](references/routing-matrix.md); do not silently substitute an explicitly required generation. A role bound to GPT-5.6 Luna remains GPT-5.6 even when named `luna_worker`.
+
+Retire Terra from recommended routes and automatic fallbacks: Sol owns ordinary implementation and investigation. Preserve explicitly pinned models and existing configuration; editing this skill does not authorize rewriting them.
+
+Use the lowest adequate supported effort. Use none only for straightforward extraction/conversion when the host exposes it and checks cover the result; low/medium are the usual starts for tool work. Use xhigh/max for a concrete depth need or an explicit compatible role requirement; ultra only when exposed and justified by the workload, never inferred from API support. Model choice and working role are separate. A role named "explorer" is not proof of sandbox isolation.
 
 At dispatch, specify model AND effort when the host permits selection. Otherwise omitted settings may inherit the parent or configured defaults. Prefer a self-contained contract and no history fork; use bounded history only when necessary. Respect full-history/override incompatibilities. Never claim prompt text changed a runtime parameter.
 
@@ -50,7 +71,9 @@ Use the first authorized, low-risk real child task as the capability observation
 
 Treat workspaces as shared unless isolation is confirmed. Tool schemas may lack per-child sandbox, timeout, role or close controls. Contract limits remain instructions, not enforced capabilities. No adequate child route: keep feasible work local and disclose the gap.
 
-Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices or live artifact collection.
+Read [runtime and configuration](references/platforms.md) only for configuration/CLI diagnosis. Read [routing boundaries](references/routing-matrix.md) for ambiguous choices, legacy fallbacks or live artifact collection; read [model economics](references/model-economics.md) for dated prices and cost calibration.
+
+Read [GPT-6 adaptation](references/gpt6-adaptation.md) when async execution, steering, context recovery or dynamic effort changes affect the workflow. API features are not automatically Desktop/CLI capabilities; use only exposed controls.
 
 ## Dispatch, observe, accept
 
@@ -66,4 +89,6 @@ Use [evidence packets](references/evidence-packet.md) when structured evidence i
 
 Load only needed references; keep long logs on disk. Avoid whole-history forks and repeating contracts, packets or prior findings. Account for parent context/reasoning, child usage, waiting, retries and integration when evaluating cost.
 
+After steering or context compaction, recover the current objective, accepted corrections, permissions, baseline, file/semantic owners and pending tool/child IDs before continuing dependent work. Retain valid completed evidence; revalidate only results affected by the change. A queued correction is not proof that a running writer has stopped or adopted it.
+
 Production read-only collection is routable by work shape; mutation and final semantic acceptance stay parent-owned. Do not silently relax a project's literal model-owner requirement. Identify the actual rule and resolve it only through authorized changes.