Claude Maestro — Claude conducts Codex: analyzes a task, writes acceptance criteria, decides single vs N parallel Codex sessions, auto-routes models, dispatches via codex app-server, observes progress, verifies results with diff review + build/tests, and drives a rework loop (≤3 rounds) before escalating. Use this WHENEVER the user wants implementation work done by Codex/GPT sessions — no explicit /maestro needed. Triggers include: 'maestro', any ask to delegate/hand off coding to codex ('have codex do this', 'let codex implement', 'send this to codex', 'ask codex to fix'), Korean phrasings ('codex로 처리', 'codex한테 시켜', '코덱스로 해줘', '코덱스에게 맡겨'), or requests to run/steer/verify Codex sessions. Even when the user does NOT mention codex: for a substantial implementation task (feature + tests, multi-file change, parallelizable work), OFFER maestro with a quick yes/no question before proceeding — see 'Offering maestro' in the skill body.
Render the maestro mixed performer status view — one at-a-glance table of ALL currently running performers: codex sessions (app-server) AND Claude background subagents, plus not-yet-closed maestro units. Invoke on: '/maestro-workflows', 'maestro-workflows', 'maestro workflows', '지금 뭐 돌고 있어', 'what are the performers doing'. This is the conductor-rendered counterpart of Claude Code's /workflows for maestro runs.
Invoke when deciding what to load into context, what to persist across turns or sessions, and what to drop — reads only what the task needs, writes durable handoffs, avoids context pollution, and chooses when to re-derive versus recall.
Invoke when deciding whether to split work across parallel agents/sessions or do it inline — tests scope independence, weighs coordination cost against the parallelism win, and sets an observation cadence for delegated work.
Invoke when writing any status, completion, or result report — calibrates claims to the evidence actually gathered, marks the unmeasured as open, reports failures plainly, and distinguishes "verified at layer X" from "should work".
Invoke before acting on any assumption about the runtime or environment — versions, running processes, file/disk reality, git state, network reachability. Grounds claims about the world in a cheap probe instead of a guess, and re-probes when state may have gone stale.
Build an accurate mental model of an unfamiliar codebase or problem before making any edit — structural scan, entry-point location, one end-to-end trace, and an explicit known-vs-assumed ledger.
Systematically enumerate how code can break — boundaries, concurrency, partial failure, malicious input, time, resource exhaustion — before writing defenses, then convert the list into tests and guards while pruning paranoia that does not pay rent.