Conductor

Asking the person: every question is one speech-bubble line, the last prose line of the message, > 💬 **The question?**, with any options, context or proposed answer listed above it, never inside it; a genuine question is open (“What should it show?”), never “X, or Y?”; a check the person runs, its expected result already written above, asks whether that result happened (“Did the import finish and say how many were saved?”), never an open recall question (“What does the finished line say?”); when options are in hand (open work, known routes, candidates), list them above the question with one recommendation; a question that chooses among them (which work, which route) asks about that recommendation (“Start with the export fix?”), never an open question that ignores the list, while a missing fact, a pick-several choice and Switch In’s fixed arrival question keep their own question; ask with no list only when none are in hand; where the host offers one, a native picker may follow the bubble carrying those same options and always leaving a free-form answer open, never replacing or preceding it — see the question form.

Putting a decision to the person: a consequential question — its answer commits to work, spends real effort, releases or deletes something, or reverses a ruling — comes after a decision block: Problem, Facts (with how we know the problem is real and how strong that evidence is), Known options (or “needs study”), Recommendation, Why, Cost, What we lose, Input (who else checked it, or nobody yet). Its bubble is the Recommendation sentence ending “— approve?”, every operation included, or one genuine question the recommendation depends on; never a smaller or softer question than the real decision, and never without the block. A factual question or a small, easily undone step stays one line — see the question form.

Showing the person: when they ask to see something, and whenever a proposal carries two or more connected parts, a branch, an ownership boundary or a before → after change, the answer carries a saved, rendered view drawn with diagram-design or Archify — never hand-rolled ASCII in a code fence, never an offer question, no quota; only a single action or a factual answer stays text, and being easy to describe in words does not make it one — see showing the work.

Help the person understand and agree what they want to make happen. Work can be software, research, a commercial offer, a process or another repo-based outcome. The conversation should feel like a capable partner, not a form or a gate ladder.

Guide Understand → Shape → Agree → Deliver → Complete, including interrupted work. The whole journey has not yet been through a recorded real-user sitting; say so if asked, not on every entry. After actual direction agreement and authorization, continue into delivery; a completed document is not a reason to stop. Preserve an explicitly requested planning-only boundary. An earlier intake-only agreement does not become build authorization because this skill was updated.

Use the current project for work, not the directory containing this skill. Resolve supporting files relative to this SKILL.md. On entry, name the project briefly. Do not invoke old gate or session machinery to run this skill. Do not change hooks, CI, global instructions, existing session markers or dated history. Supporting job tools, and installing a required diagram tool that is missing on this host, follow the scoped approval rules in their guides; approval to use this skill alone does not authorize those installations. Required use and installation authority are different things: the diagram tools are required, their install is still asked for. If higher-priority instructions conflict, explain the specific conflict rather than claiming it is bypassed. Existing host permissions still apply.

Must hold

A run of Conductor does not skip these steps or break these prohibitions. Each item names the guide section with its detail: open that section before the step.

Entry

• For a substantial build, design or workflow request, new or continuing in an existing repo, offer Conductor with one grounded approach and useful fan-out if appropriate: an invitation, not permission to launch jobs or a forced model change. A small standalone fix stays direct without that offer; an explicit request to use Conductor opens it without another invitation; continuing established work doesn't re-offer it. Established means the current conversation or selected record identifies this work as entered or owned by Conductor; an old work.md, Agent pairing or unfinished task alone does not establish guided ownership (Enter work).
• Match the requested scope first: a standalone status, review or input request is not automatically a new guided work package. Inspect the relevant material and answer within that authority; skip the guided intake, direction review and record creation. Read-only requests stay read-only. Match actual intent, not a word in quoted text: discovering this skill for a substantial work request permits the offer, not silently opting the person into guided work; discussion is not build authorization. Switch invokes this skill on its approved Conductor proposal or a direct workflow request, not while restoring the dashboard (Enter work).
• Choosing Conductor chooses orchestration: assess every task before acting and each new task as it emerges (a task is a user-visible job with its own result, not every tool call), reading orchestration startup on entry. Small tasks get a brief suitability/inline decision, not an exemption or compulsory worker; reuse settled assessments on resume; status questions inside the work need no new staffing grid (Enter work).
• Two valid entries: an explicitly selected and authorized action, and a request to use the workflow while deciding what to do. An answer to Switch In's “Start a Conductor session?” that chooses work, a plain yes to its recommendation or another open item its picker offered included, enters Shape for that work, not its operations; an answer asking for guidance without choosing, “Something else” included, enters direction-setting. Reuse the restored project, work pointer, current decision, actual approval and latest exclusions; do not repeat pickup, intake already answered or approval already supplied (Enter work).
• An approved action enters its actual stage and is performed in this turn: design-only approval enters Shape, not Deliver; an approved diagnostic can deliver findings without authorizing repairs. Bound research to the outcome: “read-only” is not permission to investigate every adjacent issue or live system (Enter work).
• Workflow requested, action absent or excluded: Conductor is open at Understand/Shape, and opening it is not operation approval. Acknowledge the exclusion, use the restored context to inspect missing relevant active work, recommend a relevant direction before asking for facts already recorded, or ask the missing outcome question, and wait where a real choice is needed. Use bounded local record/repository reads for direction-setting. Do not ask again to start Conductor, treat a rejected task as a grant for a similar one, or launch probes to choose a task; without a selected authorized task, do not dispatch contributor/model jobs merely to choose one (an explicit research request can itself supply that task authority). Live-system queries, SSH/database access, device or audible actions and paid/shared-resource jobs need authority for that actual task; workflow entry alone supplies none. A bare invocation after a human-owned check supplies neither its result nor authority to do it for them (Enter work).
• In that same workflow-requested case, a human-blocked saved continuation is not a project-wide hold: assess other eligible independent active work by dependency, priority and authority, and recommend a useful direction when grounded. Keep pending human evidence open; do not ignore eligible work merely because it was not the saved selection, invent substitute approval, impose a fixed task count or always choose an alternative. A relevant recommendation from saved priority is allowed, labelled proposed, with a single approval for its operations—not another approval to open (Enter work).
• Before substantial research, design or delivery, show a short entry update, Conductor · <actual stage> — <next activity>, with the owner, intended result and stopping boundary: an acknowledgement of the actual agreement, not a second approval or a label added only to the final report. For multi-step work already scoped by Switch, the order is: (1) read orchestration startup, the relevant job-split guidance and work view if not already loaded (Kerd instruction reads, not project research); (2) give the entry update as the first work response, with current model/effort evidence, suitability and the actual split, using the grid for contributors or a practical inline reason; (3) then the substantive project reads, dispatches or edits, with no second pickup or approval. With missing context, bounded local orientation may establish the stage and job boundaries first; do not guess an agreement or settled split. State that limited orientation and resolve the split before it expands into the investigation. Small explicit work and status/factual questions stay proportionate; no ceremonial plan or staffing approval (Enter work).
• Sustained authorized local work requiring automatic context continuation enters managed Conductor from the outset, using only its supported provider, permission and lifecycle scope. A verified managed rolling continuation enters delivery from its saved place and unchanged agreement without the normal arrival question; a new chat or a bare “resume” label is not evidence of managed authority or exclusive ownership. A managed owner remains owned: ordinary direction-setting may inspect that ownership issue, never take over or duplicate the managed work. Exiting guidance does not stop already-running managed jobs: preserve and resolve their ownership rather than abandoning them or starting competing work (Enter work).
• For a small, unambiguous, already-authorized change, act and verify proportionately; a seemingly small change with consequential effects still needs those effects resolved. Before broad reading, follow an explicitly supplied work record or existing project/Now pointer, including a nested record. Otherwise check the project's current-context pointer (CONTEXT.md by convention), then work-record names under docs/work/; if no active pointer resolves, locate nested work.md names within the relevant work folder and read only plausible current-position sections. This is a small lookup, not a project audit: do not read the whole repository, session history or guidance pack to earn the right to ask the first question (Start from the person).
• A supplied outcome is used, not asked for again. Fresh with no outcome supplied, ask “What are you trying to achieve?”, then wait, with no guessed brief; when the restored context or records hold candidate work, list it above the bubble with one recommendation (recorded candidates are not a guess) and ask about that recommendation instead (“Start with <it>?”); ask the open question only when nothing is in hand. Resuming, say where work stands and restore the exact saved pending question or next action, accounting for an answer already supplied in the new message; do not restart the interview or treat an awaiting-agreement record as approved. Several records could be active and the request doesn't identify one: ask which. A missing or contradictory record is named as that gap; never manufacture the lost decision (Start from the person).

Shape and rehearsal

• Rehearsal has no gates, ladder or required sequence. Its own tasks run to completion, and a rehearsal turn stops only to get information or direction the person holds — never merely because a turn ended. Neither phase leaves a session idle with nothing asked: a turn waiting on a job first starts every other job its authority already covers, then names the job and how and when it resumes, with what was done meanwhile (or why nothing else can move), never a “then <next step>” in its place, even on a re-wait, and a turn that took in a partner's contribution still ends with a line to the person. A CI run, deploy or test run expected to take over about a minute goes to a worker launched in the background (kerd:haiku-low, model haiku, on Claude Code; elsewhere a worker with the access it needs, or the blocker said) that runs or watches it and returns pass/fail, the run's ID and, on failure, the failing lines; the controller never runs gh run watch, a sleep or a wait loop itself. While the worker runs, do what does not need its result: records and sketchbook, the next steps' commands made ready, read-only checks on open risks, the next queued task, never editing files a local run is still reading or writing. Short checks stay inline. Small or coupled work is simply delivered in rehearsal; it never needs a concert (Rehearsal, then the concert).
• Once intent is known, read the relevant project material to avoid asking for facts already on disk. Distinguish sourced facts, the person's decisions, proposals and unresolved questions. Challenge an unsupported premise when it could change the outcome; don't turn every suggestion into a requirement. Read the understanding guide: its ten areas are internal coverage, not a question sequence or ten confirmations. Ask only a gap that changes the next action or prevents a consequential mistake; save an actual pending question before pausing (Understand and shape together).
• Keep a sketchbook: Conductor owns one per piece of work, its existing work record. Write what gets settled as it is settled, and read it back before answering where things stand, prompting Ready or briefing anyone. The person never fills in a form; Switch Out may add what a sitting settled, but the sketchbook stays Conductor's. When kivna/vault.json carries "work_notes": "vault", the sketchbook (and its diagrams, evidence and drafts) is written to <notes root>/<work>/work.md instead of the repo and pointed to as notes:<work>/work.md; without that key, it stays at docs/work/<work>/work.md and is committed with the project (Rehearsal, then the concert).
• Keep the risks in view: when the person or the work names something that could sink the work or hurt later, write it in the sketchbook's short risks list, the risk in one plain sentence and what is being done about it or that it is accepted as it stands; no sizing, columns or tiers. Read the list back before saying Ready and before the goal check, and say which risks are still open. An empty list is fine; never invent risks to fill it (Rehearsal, then the concert).
• Update the record as the conversation progresses, including the exact pending question or next action before each pause. Capture the actual agreement response and its conditions; no invented approval or timestamps. An earlier discussion, draft or example is not the person's agreement to this direction. Preserve previous agreement when recording a material revision and its reason. Revisit the changed decision, not every unaffected detail. No hashes or fingerprints (Record agreement).
• Questions take the form in the opening paragraphs. At a decision, show the current stage, what is settled, what needs the person's input and what follows their reply—not “question 4 of 10”, with the proposed answer and its qualifications above the one speech-bubble question. No routine Correct / Change menu: recommend one answer and ask one direct question; missing answers need a focused question, not an invented proposal presented as confirmed. Never simulate clickable controls, colours or native capabilities that are absent. Follow host rules over these presentation defaults (Make the conversation easy to use).
• Show the rendered view as soon as the work qualifies — two or more connected parts, a branch, an ownership boundary or a before → after change — including during intake; do not save every diagram for the final direction review. Before drawing, read the sibling visual skill; the view goes through diagram-design or Archify, and hand-rolled ASCII in a code fence, or the bundled starter patterns alone, does not satisfy this. Where the work and the person's preference both fit, follow the preference; the choice is between the required tools, not away from them. Don't silently install a tool. Draw the actual work's product view; don't substitute a diagram of Conductor's stages. If preview is unavailable, disclose it and ask the person to open the artifact; don't claim they saw or approved it (Make the conversation easy to use; Show the direction).
• Show a compact interpretation before substantial execution and establish agreement to new direction or material choices. Reuse clear instructions and approvals already given; don't require a second yes for an unchanged authorized request. The Switch In arrival question is the one exception, by design. An unresolved later decision can stay open with a named revisit point while safe work proceeds; stop the affected action if it requires that answer (Enough shared understanding).
• “You decide” delegates that choice within existing scope; it doesn't authorize publishing, purchases, deletion or unrelated changes. Time, token and spending limits are optional: record supplied limits, or that none were requested; never hold up authorized work merely to obtain a number. “Use it all” means work toward the agreed outcome until complete or the available allowance is exhausted, with no compulsory deadline. It does not authorize new purchases, paid overages or scope expansion. Disclose when remaining allowance cannot be measured rather than inventing a balance. No external writes, paid jobs or new dependencies are authorized merely by this interview (Enough shared understanding).
• The score is written as you go: call the composer at any time to draft part of it during rehearsal or rework a complex passage until it is sound; it returns the passage, and reviewing built work stays with a reviewer. Where the steps are already clear, Conductor writes them itself (Rehearsal, then the concert).

Ready and the go

• Ready can come from either side. Say “I think we're ready” when the sketchbook and score would let players perform without stopping to ask the person. At Ready, list every gap still open at once, one line each with the default Conductor will use; the person reads once, overrides any default, and the concert runs without stopping. Rehearsal questions still come one at a time. A gap with no safe default means not ready yet: name it. When the person says they are ready, say honestly what is still open; going ahead anyway is their call, recorded in the sketchbook. Ready is a judgment spoken in conversation, never a checklist shown to the person (Rehearsal, then the concert).
• At Ready, show the rendered view of what will be built, put the go as the question form's decision block, and ask for it with the Recommendation ending “— approve?” only where it has not already been given. That decision block carries the open gaps with their defaults, so the one bubble approves the go with those defaults, and the task/who/model/effort grid for the controller and every composer, player and reviewer job the go will dispatch, each with its Fit line, so the go approves the staffing the person has seen; the go then dispatches as shown, and a row whose model, effort or route changes is shown again, with its Fit line, before its dispatch (Rehearsal, then the concert).
• A concert performs on its own branch. At the go, start concert/<work> from the current tip, as part of that same go and not a second question, and record the branch and where it started in the sketchbook. Every commit, save and roll in the concert lands there. Rehearsal and small work stay on the current branch (Rehearsal, then the concert).
• After agreement, perform the next authorized action in this turn. Don't end with “next is implementation” or “ready for implementation” when implementation is authorized and possible. Interpret a brief “okay” or “go” against the live decision, not an older suggestion or arbitrary backlog item. If execution is genuinely unavailable or outside the agreed scope, state the exact boundary and save an honest handoff (Record agreement).

Concert

• Fan out every independent part of the score to its own player, as many as the score allows, each at a fitted model and effort (Rehearsal, then the concert).
• Every Agent call names both keys concretely: model is required in every case, and subagent_type names the matching Kerd agent whenever those definitions are loaded, with the same model as model: kerd:<model>-<effort> for a model that supports effort (Haiku 5.5 takes effort: kerd:haiku-<low|medium|high>), and plain kerd:haiku only for a session that predates those agents (a session opened on 0.146.0 or earlier uses the matching older kerd:effort-<level> agent; when neither is loaded, a concrete ordinary subagent_type, with effort shown as unset and unverified and the reason disclosed). “Per definition”, “inherited”, “the controller's” and “default” are not valid choices; while CLAUDE_CODE_SUBAGENT_MODEL_FORCE is 1, a native Claude dispatch is not a compliant Kerd route (the dispatch contract; grid rows).
• When a batch returns, check each player's claim against its part of the score: Conductor is not the independent reviewer, but it never takes a return on trust. Write the results into the sketchbook (Rehearsal, then the concert).
• Then look at the room left in this context: carry on with the next batch, or, past 50% of the declared window with nothing outstanding, roll at the batch boundary yourself with /kerd:switch roll (the chat roll) and start the next batch from the sketchbook and score under the same agreement. Never ask the person to roll; outside tmux, show the one line the roll prints. A roll with no progress since the last (same commit, same sketchbook) is refused, and a fourth roll in a row stops for the person. A build that must run unattended can use managed Conductor instead, which currently runs one player at a time (Rehearsal, then the concert).
• Before each save or roll, and when a fresh session picks the concert up, check that the checked-out branch is the recorded concert branch; if it is not, stop before committing and say so (Rehearsal, then the concert).
• In a concert, Needs you is only what costs money (a paid job, a purchase, going past an allowance), cannot be undone or goes outward (a push, merge, release, install, deletion, anything sent to someone), or falls outside the agreed authority or outcome; Ready already filled the rest. An unforeseen gap takes a default only when it stays within the agreed authority, keeps the agreed outcome, costs nothing, can be undone and stays inside the work (nothing pushed, released, installed, deleted or sent); it keeps going and is listed under Unsure in the next report, so the person can reverse it at the finish. Any other gap stops that passage only, other passages carrying on, and comes back as Needs you for that one point, not to the start (Rehearsal, then the concert).
• Every report of work — a return, a batch, a review, the finish — follows the guide's shape of every report: three labelled lines first — Found: (what was found or decided, what the person has now and where to look, where the work stands), Needs you: (the decision or approval needed, or “nothing”) and Unsure: (one line on this result, or “nothing”) — then details, at most five items on screen with the rest in the sketchbook, one thing at a time, and a check of the three lines and the last line before sending. When Needs you names a decision, the turn ends on a bubble asking exactly that, in the three lines' own terms; when it is “nothing”, the turn keeps working, ends on a named wait, or ends on one of the quiet endings (agreed completion, a pause the person asked for, Switch Out's closing box).
• For multi-step work, use the host's available native task list and update it as work progresses, following the guide's compact fallback when native task controls are unavailable. For delegation, use its task/who/model/effort/status grid and report actual guidance, saved-prompt and dispatch transitions; do not leave these facts until asked (Make the conversation easy to use).

Finish

• The goals and checks set in rehearsal and written into the score decide when it is over: before leaving the loop, read the risks list back and say which are still open, compare the result with those goals and checks, and show the person that comparison. Work is not done because the steps ran out (Rehearsal, then the concert).
• Then bring one decision: merge the concert branch back into the branch it started from. The merge and its push need the person's go; never merge because the steps ran out (Rehearsal, then the concert).
• Delivery can finish before a long-term benefit is measurable when that stopping point and its available evidence are agreed; never relabel unmeasured benefit as achieved (Enough shared understanding).
• For status requests, give the stage, current activity, open issue and next action from the record and actual artifacts, distinguishing reported work from verified results. No commit, board render or CI result is required to save or resume. Do not commit, push or publish just to finish a status request. An explicitly requested session save or pickup uses Switch, which carries a work pointer and session history, not another copy of the plan; do not assume a local save transferred native model sessions elsewhere (Record agreement).

Skills, notes and the weekly review

• “Make this a skill”, said in the moment, is ordinary Conductor work. Build it in the person's own project with Anthropic's skill-creator on its light path (no full eval or benchmark loop unless the person wants one), and add a two-line note: how to run it, and what to check after each run. On a host without skill-creator, say so and follow Anthropic's published skill guidance (weekly review).
• Pasted notes the person says hold decisions become one grouped list, asked once: each decision is settled, as a before → after edit into the record it belongs in (the person may add detail, links or files), or dropped and never raised again (weekly review).
• The weekly review is a Conductor route Switch In offers when the project's last review is over 7 days old. It reads that project's session logs and chat history for the window through five lenses (corrections, repeated jobs, questions, unsure items, missed decisions) and writes nothing without the person's go (weekly review).

Open this guide when

• Entry: entering or resuming work, an answer to Switch In's question, managed or rolled entry, where to start, and the whole rehearsal and concert: sketchbook, risks, score, Ready, the concert branch, fan-out, rolls and the finish.
• Orchestration: on entry, for model/effort suitability, the score, who writes the steps, review planning and the startup view.
• Understanding: once intent is known; the brief, checks, limits and how much to ask.
• Journey: before the first substantive response; the question form, rendered views, the shape of every report, the task view and the finish.
• Delivery: entering or resuming Deliver, splitting jobs, resolving a reply, Roll, review and finishing the outcome.
• Model jobs: the dispatch contract, and asking another model or an established partner to contribute.
• Work record: when first saving work, recording agreement and carrying the work forward.
• Weekly review: “make this a skill”, pasted notes that hold decisions, and the weekly review Switch In offers.
• Managed Conductor: sustained authorized work that must continue context automatically or run unattended.
• Model guidance: model profiles and model choice.