In a symphony orchestra, a premiere performance is never improvised. Long before the first downbeat, the composer has written a full score — every instrument's part woven together across hundreds of pages of notation. But no musician performs from the full score. The orchestral copyist extracts individual parts — violin I, second oboe, timpani — each complete, self-contained, and ready to play without referencing the master document. The conductor studies the full score, shapes the interpretation, and coordinates dozens of musicians who may never see each other's parts. And when something goes wrong mid-performance — a missed entrance, a broken string, a miscount — the ensemble has protocols: the concertmaster signals, the conductor adjusts tempo, and the performance continues without the audience ever knowing.
The Elevated Stage applies this centuries-old orchestral model to autonomous software development with Claude Code. Each skill in the suite fills a distinct role in the ensemble — from research-driven design exploration through phased implementation planning, coordinated multi-session execution, and automated fault recovery. The skills communicate through a shared database, follow strict protocol contracts, and operate on the same principle that governs every professional orchestra: each performer plays from prepared, self-contained material, coordinated by a single authoritative conductor.
The system operates on a three-tier execution model. The Conductor coordinates from a dedicated context window, Musicians execute in isolated terminal sessions, and Subagents handle focused work units within a Musician's context:
Tier 0 — Conductor (coordination layer, 1M context)
├─ Tier 1 — Musicians (implementation, external sessions)
│ └─ Tier 2 — Subagents (focused work within Musician context)
├─ Tier 1 — Copyist (task instruction generation, teammate)
├─ Tier 1 — Repetiteur (re-planning on persistent failure)
└─ Tier 0 — Souffleur (Conductor liveness watchdog)
Before the Conductor picks up the baton, two preparatory roles set the stage:
Dramaturg → Arranger → Conductor → Musician
(design) (plan) (orchestrate) (implement)
The Dramaturg explores what should be built. The Arranger transforms that vision into a phased implementation plan with machine-readable section boundaries. The Conductor then drives the plan to completion — dispatching Copyists to prepare task instructions and Musicians to execute them — while the Souffleur watches from the wings, ready to intervene if the Conductor falters.
All orchestration state lives in the database, not in session context. Context is ephemeral; the database is the source of truth.
In traditional theater, the dramaturg is the resident scholar — the one who researches the historical context of a play, advises the director on interpretation, and ensures the production stays true to its source material while remaining relevant to its audience. A good dramaturg doesn't just accept the director's first instinct; they pressure-test it against research, offer alternatives, and help shape a vision that's both ambitious and grounded.
The dramaturg skill brings this research-first philosophy to software design. Rather than jumping straight to implementation planning, the Dramaturg engages in fluid, conversational design exploration backed by active external research. It validates technical approaches in real-time — checking whether a proposed architecture actually works with the current version of a framework, whether an API behaves the way the user assumes, whether a pattern has known pitfalls in production. The Dramaturg doesn't just accept a design brief and run with it; it interrogates the brief, explores alternatives, and produces a design document that has been pressure-tested against reality.
Two key artifacts emerge from every Dramaturg session: design documents that capture the validated vision, and decision journals that record the reasoning behind every significant choice. These journals become invaluable downstream — when the Conductor needs to understand why a particular approach was chosen, or when the Repetiteur needs to re-plan around a blocker without contradicting earlier design decisions, the journal provides the context that a design document alone cannot.
In an orchestra, the arranger takes a composition and adapts it for a specific ensemble — deciding which instruments carry the melody, where the tutti sections land, how a four-movement work divides into rehearsable sections, and where parallel voices can be introduced without muddying the texture. The arranger's craft is taking musical intent and making it practically performable by real musicians in real rehearsal time.
The arranger skill converts Dramaturg design documents into phased implementation plans through a six-phase workflow: ingestion, feasibility audit, implementation discussion, phase structuring, section writing, and finalization. Every implementation decision is settled here — protocols verified via Gemini and web search, settings validated through read-only code path tracing, integration points identified, phase structure optimized for parallel execution. The Conductor and downstream agents should never need to research protocols, configurations, or integration patterns — that work is done before a line of code is written.
The Arranger's output is the bridge between human-validated design and machine-executable orchestration. Each phase is wrapped in sentinel markers (<!-- phase:N -->) for machine-readable boundaries, and a plan index maps every phase to its exact line range — enabling the Copyist to extract individual phases without parsing the entire plan. The Conductor reads the plan, the Copyist decomposes it, and Musicians never see it directly — they receive only the extracted, self-contained task instructions prepared from its contents.
The conductor of an orchestra doesn't play an instrument. They don't write the music. They don't copy the parts. What they do is hold the entire performance in their head — every entrance, every dynamic shift, every transition between movements — and coordinate dozens of independent musicians into a coherent whole. They listen for wrong notes, adjust tempo when the ensemble drifts, cue soloists at the right moment, and drive the performance forward from first note to final chord. A conductor's value isn't in doing the work — it's in ensuring the work happens correctly, in the right order, and recovers gracefully when something goes wrong.
The conductor skill is the coordination layer of The Elevated Stage. It operates on a 1M-token context budget dedicated entirely to orchestration — the Conductor never does implementation work itself. It reads the Arranger's plan, launches Copyist teammates to generate task instructions for each phase, dispatches Musician sessions into dedicated terminal windows to execute those instructions, reviews their output when they pause for checkpoints, and handles error recovery when problems arise.
When a Musician reports an error, the Conductor has five correction attempts — analyzing the failure, providing targeted guidance, and sending the Musician back to retry. If five attempts aren't enough, the Conductor escalates to the Repetiteur rather than burning more context on a problem it can't solve. When all phases are complete, the Conductor verifies the integrated result across the full scope of the plan.
In a traditional orchestra, the copyist sits between composer and performer. The full score holds every instrument's line — hundreds of pages of interwoven notation — but no violinist plays from the full score. The copyist extracts each player's part: complete, self-contained, and ready to perform without referencing the master document. A good copyist doesn't just mechanically copy notes; they ensure rehearsal marks align, page turns fall in sensible places, and every part contains exactly what the performer needs — nothing more, nothing less.
The copyist skill does the same for implementation plans. It reads a single phase from the Arranger's plan — by exact line range, never the full document — and produces self-contained task instruction files. Each instruction contains everything a Musician session needs to complete its work autonomously: objective and success criteria, prerequisite checks, complete SQL patterns for database coordination, explicit file paths for every deliverable, per-step context budget estimates, verification commands with expected output, error recovery procedures, and completion reporting templates. No instruction file ever says "see plan section X."
The Copyist enforces strict protocol compliance on every instruction it generates — correct database table names, mandatory heartbeat updates on state transitions, required message fields, Tier 3 document format — and validates every file through machine checks before returning it to the Conductor. The Copyist test is simple: can a Musician session execute this instruction file from start to finish without loading any other document?
The musician in an orchestra takes their prepared part, sits at their stand, and performs. They don't question the orchestration, rewrite their part mid-performance, or peek at the first violin's line to figure out what they should be playing. They execute with skill and precision, watch the conductor for cues, and trust that the part they received is complete and correct. If something goes wrong — an ambiguous marking, a missing bar — they signal the conductor and wait for direction rather than improvising a solution that might clash with the rest of the ensemble.
The musician skill executes phased task instructions in external Claude Code sessions, each launched in its own dedicated terminal window. Every Musician claims its assigned task atomically through the database — an UPDATE with a guard clause, verified to affect exactly one row, ensuring no two Musicians can claim the same task. The Musician then follows the instruction's steps in order, delegates large work units to Tier 2 subagents when appropriate, commits its work at review checkpoints, and reports results back to the Conductor through structured database messages.
Musicians manage their own context aggressively. They monitor usage at 50%, 65%, and 75% thresholds, with a mandatory checkpoint and exit at 75% — because context exhaustion in an autonomous session means lost work with no recovery. Every state transition updates a heartbeat in the database, giving the Conductor and Souffleur continuous visibility into whether the Musician is still alive and working.
In opera, the répétiteur is the rehearsal pianist — the one who works with singers between full orchestra rehearsals, helping them learn difficult passages, navigate tricky rhythmic shifts, and build confidence in sections where they've been struggling. When a performer hits a wall, the répétiteur doesn't replace them or rewrite the opera; they analyze what's going wrong, adjust the approach, and prepare the performer to succeed in the next run-through. The goal is always to keep the production moving forward without escalating to the full ensemble or the director.
The repetiteur skill is the autonomous mid-implementation re-planner. When the Conductor has exhausted its five correction attempts on a stuck task — the same error keeps recurring, or the Musician reports a structural blocker that targeted guidance can't resolve — the Conductor escalates to the Repetiteur. The Repetiteur examines what's been tried, analyzes the blocker in the context of the original design and the current codebase state, and produces a revised plan section that routes around the obstacle. It does this entirely autonomously, without requiring user intervention, preserving the pipeline's ability to run unattended.
The Repetiteur has a hard cap of three consultations per feature. This prevents the system from entering infinite re-planning loops — if three re-plans can't resolve the issue, it's a design problem that requires human judgment, not another automated attempt.
In theater, the souffleur sits in a small hooded box at the front edge of the stage, script in hand, invisible to the audience. Their job is entirely invisible when things go well — the actors remember their lines, the cues land on time, and the souffleur simply follows along. But when an actor blanks on a line, or the pace stalls, or a scene transition goes wrong, the souffleur whispers the next line from the darkness, and the performance resumes as if nothing happened. The audience never knows. The best souffleurs are the ones you never notice.
The souffleur skill is the external watchdog that monitors Conductor liveness. Launched at the start of execution in a completely separate session, the Souffleur watches the Conductor's process ID and database heartbeat. If the Conductor fails to heartbeat within the expected interval — whether from context exhaustion, a process crash, a provider timeout, or any other failure mode — the Souffleur steps in. It recovers the orchestration state from the database (which is always the source of truth), determines where the Conductor left off, and relaunches it with provider-routed context recovery. The performance continues from where it stalled, and the user may never know there was an interruption.
Every professional orchestra has a repertoire — the collected body of works that forms the ensemble's shared musical vocabulary. When a conductor programs Beethoven's Fifth, every musician already knows the language: the conventions, the standard interpretations, the performance practices. The repertoire is what allows musicians from different training backgrounds to sit down together and play as one ensemble from the first rehearsal.
The repertoire repository holds the shared contracts and reference formats consumed by multiple skills across the suite. Priority chains that govern trade-off decisions (compatibility before reliability before efficiency). Verification rules that define what must be externally validated versus what can be self-checked. Journal conventions for the append-only decision logs that flow from Dramaturg through Conductor. Output format specifications with sentinel markers that make plan documents machine-parseable.
When a Copyist generates an instruction file, it references the same coordination schema that the Musician will use to report back. When a Conductor evaluates a Musician's output, it applies the same verification rules that the Copyist embedded in the task instructions. The repertoire is the shared vocabulary that makes this possible.
Behind every theatrical production is a production office — the administrative backbone that handles season planning, cross-department coordination, venue logistics, and the thousand details that never appear on stage but without which nothing would happen. The performers rarely interact with it directly, but every smooth performance traces back to decisions made in the production office months earlier.
The stagecraft repository is the meta-documentation and planning layer for The Elevated Stage. It holds overarching reference designs — including the Arranger specification — expansion planning for future skills, cross-cutting review archives, and documentation that spans across individual repositories. When a new skill is being designed, or an existing skill needs significant revision, the design work happens in stagecraft before migrating to the skill's own repository. It's also where the architecture-level decisions live: the three-tier execution model, the database-driven state philosophy, the protocol contracts that bind the skills together.
When a project begins, the user works with the Dramaturg to explore what should be built. Through conversational, research-backed exploration, the Dramaturg validates technical approaches, pressure-tests assumptions, and produces a design document accompanied by a decision journal that records the reasoning behind every significant choice.
The Arranger takes that design and transforms it into a phased implementation plan — identifying dependencies, organizing parallel and sequential work groups, wrapping each phase in machine-readable sentinel markers, and building a plan index that maps every section to its exact line range.
The Conductor picks up the baton. For each phase in the plan, it launches a Copyist teammate to extract self-contained task instructions from the plan's phase section. The Copyist reads only its assigned line range, produces validated instruction files, and returns them to the Conductor.
The Conductor then dispatches Musicians — each running in its own terminal session, each claiming its task atomically through the database — to execute the task instructions. Musicians follow their instructions step by step, delegate focused work to subagents when appropriate, commit at review checkpoints, and report results back through structured database messages.
If a Musician hits a problem, the Conductor analyzes the failure and provides correction — up to five attempts. If the problem persists beyond what targeted guidance can resolve, the Repetiteur is called in to re-plan around the blocker autonomously, without requiring the user to intervene.
Throughout all of this, the Souffleur watches from the wings. If the Conductor's heartbeat goes silent — context exhaustion, process crash, provider timeout — the Souffleur recovers the orchestration state from the database and relaunches the Conductor. The performance continues.
The curtain falls when every phase is complete, every Musician has reported success, and the Conductor has verified the integrated result across the full scope of the plan.
