I installed dev-orchestra in Claude Code and ran development from a single sentence

Introduction

Last time, I introduced what dev-orchestra can do. This time, I actually install it in a Claude Code-only environment and use it.

• Expect about 5 minutes to read and about 10 minutes to try it
• This assumes Codex is not installed (using it with Codex is the next post)

dev-orchestra is open source on GitHub (MIT license). If it looks useful, a star would mean a lot.

→ github.com/istb16/dev-orchestra

What you need

Item	Notes
Claude Code	Already logged in
Python 3.11 or later	Runs on the standard library only
git	Used to get the diff to review

No API key is needed. It uses your existing Claude Code login.

Steps

1. Install it

Two lines in the terminal.

claude plugin marketplace add istb16/dev-orchestra
claude plugin install dev-orchestra@dev-orchestra

From inside Claude Code, typing the following does the same thing.

/plugin marketplace add istb16/dev-orchestra
/plugin install dev-orchestra@dev-orchestra

It becomes available in sessions you open after installing.

2. Pick a preset on first use

The first time you make a request that uses dev-orchestra, it notices there is no configuration yet, shows you the current setup, and asks you to pick a preset.

A preset is a choice of “where to spend money (tokens)”, and there are three.

Preset	In a nutshell
quality	Uses strong models more. Quality first
standard	Pick this if unsure. A balance of quality and cost
fast	Mostly lighter models. Speed and cost first

I will cover what is inside the presets in detail later in this series, so here I go with standard.

The initial setup also asks which language it should reply in. If you choose Japanese, a hook to “reply in Japanese” is added to your Claude Code user settings.

3. Confirm it is built from Claude alone

This is the part I most want you to look at. On a machine without Codex, choosing standard gave me this setup (an excerpt of config show in dev-orchestra 1.0.0).

Preset: standard (implicit; fitted to claude)
  note: codex not found on PATH: reviewer seat 2 (general) went to claude as claude-general-2 (sonnet)

  Architect
    claude / fable / latest
  Implementer
    claude / opus / latest
  Reviews
    1. claude / opus / latest / general / claude-general
    2. claude / sonnet / latest / general / claude-general-2
    3. claude / sonnet / latest / security / claude-security (opus when high-risk)
    4. claude / sonnet / latest / test / claude-test

The reviewer seat that would normally go to Codex was automatically replaced with Claude (sonnet). So you don’t end up with a configuration that assumes a CLI you don’t have, with reviews failing every time.

• Design uses fable and implementation uses opus: the model is split by role
• There are 4 reviewers. All are Claude, but they run as separate processes that don’t have the conversation from implementation
• The 4 reviewers also have different roles: general, security, and test

4. Check that everything is ready

To be safe, I asked the agent “Run dev-orchestra’s doctor” to check the environment. The Claude Code part looked like this (excerpt).

Claude Code (claude)
  Installed: yes
  Model selection: supported
  Models (cli-help): fable, opus, sonnet
  Read-only runs: enforced by --permission-mode plan --disallowed-tools Edit,Write,NotebookEdit --tools Read,Grep,Glob --strict-mcp-config --restricted

Read-only runs: enforced means that the design and review roles are forced to run read-only by Claude Code flags. It is not asking them “please don’t edit”; it simply never gives them tools that can edit.

If it ends with No problems found., you are ready.

5. Make a request in one sentence

From here, you just talk to it as usual.

Implement this issue with the configured workflow

Write tests for this function and run it through the multi-model review

To let the implementer run tests, first add your test command to permissions.allow in .claude/settings.json (e.g. Bash(npm test:*)). Without it, shell commands are not run automatically.

Only the steps needed for the size of the request run. For a larger request, it goes like this.

1. Design: writes a plan and asks “OK to proceed with this plan?”
2. Approval: once you read the plan and say OK, it moves on to implementation (it does not proceed on its own)
3. Implementation → tests
4. Review: 4 reviewers review the same diff without seeing each other’s reviews
5. Triage → fixes → re-test
6. Final report

The final report comes back in a form like this (example).

Tests      ✓ 12 passed
Reviews    4/4 ✓
Triage     5 findings → 2 accepted, 2 rejected, 1 duplicate
Models     architect Claude/fable, implementer + fixer Claude/opus
Changed    src/calc.py, tests/test_calc.py
Remaining  none

It even reports which findings were accepted and which were rejected, so if a finding catches your eye you can ask why.

Because it runs several reviewers, it uses more tokens than doing everything with a single AI. I recommend starting with small requests.

Features and limitations specific to Claude Code

Here are the points worth knowing when using it with Claude Code (as of dev-orchestra 1.0.0; see providers.md for details).

	Details
Plus: The strongest read-only enforcement	Design and review run with only 3 tools (Read / Grep / Glob) and use no MCP
Plus: Models are specified by name	Write opus / sonnet / fable and the latest model in that line is used
Plus: Design can resume where it left off	When revising a plan, it can carry over the previous design conversation (on verified Claude Code versions)
Caveat: Your own permissions.deny does not apply in design and review	Because none of the user, project, or local settings (settings.json) are read. The architect and reviewers can read any file in the repository, so move rules that hide secret files to managed settings (explained below)
Caveat: The implementer does not run shell commands automatically	To run tests, add your test command (e.g. Bash(npm test:*)) to permissions.allow in .claude/settings.json
Not available: Design and review don’t run on old Claude Code	On versions without the required flags, doctor reports NOT ENFORCEABLE and stops the run

Use managed settings to hide .env

Managed settings is a settings file for administrators. User and project settings cannot override it, and it is still loaded under --restricted when the architect and reviewers run.

OS	Location
macOS	/Library/Application Support/ClaudeCode/managed-settings.json
Linux / WSL	/etc/claude-code/managed-settings.json
Windows	C:\Program Files\ClaudeCode\managed-settings.json (writing it requires administrator rights)

To keep the model from reading .env and similar files, write this.

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
  }
}

The location can change between Claude Code versions. Check the official documentation.

Summary

• Installing into Claude Code takes 2 lines. No API key needed
• On first use, just pick a preset. If unsure, standard
• Even without Codex, the reviewers are automatically built from Claude alone
• Design and review are forced read-only by Claude Code flags
• Then just make a request in one sentence. The plan does not move to implementation until you approve it
• If you want tests to run, allow your test command in .claude/settings.json
• permissions.deny does not apply in design and review. Move rules that hide .env and similar files to managed settings

Detailed usage is in the README. Next time, I will try it with Codex.

For how to update when a new version comes out, see Updating dev-orchestra.

All posts in this series are in the list of “dev-orchestra” posts.

GitHub: istb16/dev-orchestra (a star is always appreciated)