Repertoire

Closing-passage pipeline for an open GitHub pull request's review feedback (via the gh CLI) — a conductor that fetches every formal review, inline comment thread, conversation comment, and failing CI check; verifies all of it against codebase reality with one read-only Opus verifier (evidence decides — no blind implementation, no performative agreement); fixes only what verification confirms with sequential fixers; panel-reviews big or risky fixes with 3 diverse-lens Opus skeptics; seals every run with a staged final verdict — an evidence-based QC gate that reads each fix in full, then one cross-model Codex review over the whole PR once QC passes; then drafts thread replies (fix confirmations, technical pushback, clarifying questions) and gates pushing and posting behind one user approval. Pushes to the PR branch but never merges, never resolves threads, never force-pushes. MANUAL-ONLY — invoke only when the user explicitly asks for Coda by name or runs /coda (e.g. "run Coda on PR 42", "Coda, work through the review feedback", "address these reviews with Coda", "resume the Coda run"). Do NOT auto-trigger on generic "address the review comments", "fix the PR feedback", "respond to my PR reviews", or "go through the review comments and fix them" requests, and never on other senses of the word "coda" (a musical or document coda, the Coda/coda.io app, the film); if the user has not named Coda as this skill, stay silent and leave review handling to other workflows.

Post-performance enhancement pass over a finished codebase, feature, or module — the audience demands more. A conductor that profiles the user-named target with a read-only scout, agrees an adaptive lens roster with the user (performance, security, robustness, DX, observability, …), hunts enhancement opportunities with parallel diverse-lens Opus hunters, and verifies every call against codebase reality with one read-only Opus verifier (evidence decides — refuted calls die, feature-sized ones route to /repertoire:libretto or /repertoire:score and never get built here). Only what the user picks at the set-list gate gets implemented — on a fresh encore/ branch by sequential fixers, panel-reviewed by 3 diverse-lens Opus skeptics when big or risky, and sealed with a staged final verdict — an evidence-based QC gate, then one cross-model Codex review once QC passes. Lands a committed enhancement dossier; pushes the branch and offers a PR behind one user approval, never merges. MANUAL-ONLY — invoke only when the user explicitly asks for Encore by name or runs /encore (e.g. "run Encore on the auth module", "Encore, revisit the exporter", "do an Encore pass over this repo", "resume the Encore run"). Do NOT auto-trigger on generic "optimize this code", "improve performance", "harden security", "clean up tech debt", or "audit the codebase" requests; do NOT fire on bug reports (Tuner's territory), open-PR review feedback (Coda's), or new-feature ideation (Eureka's); and never on other senses of the word "encore" (a concert encore, the exclamation, the Encore.dev backend framework, the Encore music-notation app, the film or album); if the user has not named Encore as this skill, stay silent and leave code improvement to other workflows.

Conversation-heavy idea and feature discovery — the spark before the production line. Establish a talking range (an existing codebase, an open domain, or the neighborhood of a half-formed spark) and a focus dimension, then hunt ideas through a paced dialogue — seed sketches the user reacts to, a running idea board, and on-demand ensemble bursts of 3-4 diverse-lens Opus ideators — converge finalists through targeted refinement rounds, then drive them through a sequential vetting funnel (identity judge → compliance checker → demand analyst → feasibility estimator) where every kill verdict must be confirmed by the user via AskUserQuestion before an idea is truly dead. The terminal artifact is a ranked, vetted idea shortlist with an optional champion handed to /repertoire:libretto — never a spec, never a plan, never code. MANUAL-ONLY — invoke only when the user explicitly asks for Eureka by name or runs /eureka (e.g. "run Eureka on this repo", "Eureka, find feature ideas", "hunt ideas with Eureka", "resume the Eureka run"). Do NOT auto-trigger on generic "brainstorm ideas", "what features should I add", "what should I build next", or "help me come up with ideas" requests; do NOT fire on spec- or design-shaped requests for an idea the user already holds ("spec this out", "design this feature" — that is Libretto's territory); and never on other senses of the word (a "eureka moment", the exclamation "eureka, found it", Eureka the place, math curriculum, or TV series); if the user has not named Eureka as this skill, stay silent and leave ideation to other workflows.

Turn a rough idea into a build-ready spec through a guided design dialogue, then harden that spec with an adversarial subagent review panel (2-3 diverse-lens Opus skeptics + a cross-model Codex reviewer) before a final user-approval gate. Libretto runs the conversation and writes the spec itself; it delegates only context-gathering and the adversarial review. The terminal artifact is an approved spec — never code or an implementation plan. MANUAL-ONLY — invoke only when the user explicitly asks for Libretto by name or runs /libretto (e.g. "spec this out with Libretto", "run Libretto on this idea", "Libretto, design X", "draft a spec with Libretto"). Do NOT auto-trigger on generic "build/brainstorm/design/spec this out" requests; if the user has not named Libretto, stay silent and leave the request to other workflows.

Conductor for subagent-driven execution of an implementation plan in the current session — groups related tasks, builds each group with a fresh Opus implementer, then gates the whole branch behind an adversarial review panel (3 diverse-lens Opus skeptics + a cross-model Codex reviewer) and an evidence-based quality-control merge gate, all while keeping the controller's own context lean (it conducts and never reads code itself). MANUAL-ONLY — invoke this skill only when the user explicitly asks for Maestro by name or runs /maestro (e.g. "run Maestro on this plan", "execute this with Maestro", "Maestro, build out the plan", "resume the Maestro run"). Do NOT auto-trigger on generic "execute this plan" requests; if the user has not named Maestro, leave plan execution to other workflows.