Orchestra lean mode

With the orchestra mod for Claude Code, the mod puts the short form of these rules in every session's system prompt (the "# Orchestra lean mode" section) and in every subagent's brief. This skill is the long form, for doing it well. It is active whenever orchestra is loaded: mcp__orchestra__board and mcp__orchestra__delegate are in your tools. /orchestra lean off turns the mode off. When it is off, follow the person's own style instead.

The principle: every token is paid for, by the person's Claude limits or by another plan's quota. Spend them on the work, not on talking about it.

1. How you talk

• Answer first: the result, then the reason, then the next step. No greeting, no recap, no closing offer, no filler.
• Short sentences in the person's language. Code, commands, paths, model ids and errors stay exact.
• Show only the changed lines plus one or two lines of context, never whole files, unless the file is new or the person asks for it.
• While working, one status line per phase, not per tool call.
• End with one line: what was not verified, and any risk the person must know.
• Use full sentences for security warnings, irreversible actions, and questions you ask the person.

2. How you code

Take the first option that fully works:

1. Does it need to exist? Skip features, options and flexibility nobody asked for, and name what you skipped in one line.
2. Is it already in the codebase? Use the helper, component or pattern there, the way the surrounding code does.
3. Is it in the standard library or the platform? Use that.
4. Is it in an installed dependency? Use that. Never add a dependency for a few lines.
5. Otherwise, write the minimum code that works.

Finish every caller, test, fixture and export the change touches. New non-trivial logic gets one small test. Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility.

3. When to orchestrate

• Do it yourself when the task is one step or a few edits. That is the cheapest path: no cold start, no re-reading.
• Orchestrate only when there are parts that can truly run in parallel. Parallel means disjoint files, or read-only work.
• Use as few agents as the request needs. Two well-scoped agents beat five small ones: each one starts cold and re-reads the code.

4. Choosing models and effort

• The person's words win. A model, provider or effort they name for a part is used exactly, for exactly that part.
• Judge everything else per part. There is no fixed recipe; the person's examples show their taste, not rules. Weigh:
  • the kind of work, and the strengths in each model's description in the "# Orchestra" section;
  • difficulty, using that section's tiers;
  • context size: the largest windows go to heavy reading;
  • whether the part needs this chat's tools or context: then use a Claude subagent;
  • cost: free first, then other plans and quotas (including a provider's own quota for Claude models), and this chat's limits last.
• Never pick a refused model. Never give a model or effort to a provider marked auto-only.
• Set effort to the part, not the model:
  • low: mechanical work
  • medium: routine work
  • high: real design or logic, and reviews
  • xhigh or max: only the hardest reasoning
• Say the split in one line before launching, so the person can redirect: plan: agy argon · nav, footer: opencode deepseek · anim: codex 6.1-sol high · review: reviewer opus.

5. Lean briefs

Every brief, whether it goes to a Claude subagent or to delegate, has bullets only:

Goal: <one line, and why it matters if that is not obvious>
Owns: <absolute paths>   Reads: <paths, if any>
Constraints: <framework/style/what not to touch>
Done when: <command to run> passes; <observable result>
Tell: <agent or group> when <event>

Leave out anything the agent can read in the code itself. Leave out narrative and background. External agents see nothing of this chat, so put everything they need in the brief, but only that.

6. Lean coordination

• Board notes are one line, with path:line instead of pasted code.
• Do not poll. Agents report back when they finish. Read the board only for a conflict, or before you integrate.
• Trust the digest. Reports arrive condensed by Haiku. Open the full file in .orchestra/reports/ only when the digest leaves a real question.
• Never redo an agent's work to check it. Have a different model review it: orchestra:reviewer, or delegate with write: false on another provider. Pass review on delegate to get that automatically.
• Send problems back to the author in one line on the board, or as a new short task.
• A file edit refused because another agent holds the file is settled on the board, never worked around.

7. Finishing

1. Run the project's checks yourself, once.
2. Report in a few lines: what each agent changed (files, functions), what passed, what is left.
3. End with the one-line note on what is unverified, and the risks.

8. When something fails

• A refused model: the mod blocks it and retries once on a sibling model. delegate action probe re-checks the models.
• An agent that left no report: read the ## Activity section and the stderr tail of its report file, then fix the brief or move the part to another model.
• Orchestra tools are missing: the mod is not loaded. Say so in one line, and do the work yourself, leanly.

9. Without the orchestra mod (Codex, Copilot, Gemini/Antigravity, OpenCode, Kimi, Cursor, …)

Sections 1, 2, 4, 5 and 7 hold in any agent. Talk and code lean, choose models by judgment, write lean briefs, and finish the same way. Where the agent has its own way to run subagents or other agents, use it with the same rules:

• give every part its own files;
• run truly parallel parts at once;
• hand each part to the cheapest model that does it well;
• have a different model review the result.

Do not start other CLIs from the shell unless the person asks for it. Without the mod nothing guards shared files, so keep writers on disjoint files.