[Released] dev-orchestra: Parallel Work Units and Per-Role Instructions v1.1.0 - v1.2.1
Introduction
dev-orchestra is a plugin for Claude Code / Codex / Antigravity that takes a one-sentence request through design, implementation, testing, review by several AIs, and fixes.
This post rounds up the changes from v1.1.0 to v1.2.1 (five releases: 1.1.0, 1.1.1, 1.1.2, 1.2.0 and 1.2.1). What 1.0.0 does is covered in the introduction post.
dev-orchestra is open source on GitHub (MIT license). If it looks useful, a star would mean a lot.
Main changes
Split a plan into work units and run them side by side (1.2.0)
If a plan (plan.md) has a ## Units section, it can now be implemented as work units. Units that don’t depend on each other run side by side, each in its own git worktree, and each is merged back into the working tree file by file as it finishes.
units checkrefuses units that cannot run, such as two whose files overlap, before anything runs, and prints the order they will run in (waves)- How many run at once is
implementation.max_parallel(default 2, up to 8) - The units of one plan share a single implementer attempt
- A plan without units runs once, as before
I walk through running two units side by side in the work units post.
Standing instructions per role (1.2.1)
Instructions written under instructions in the configuration, per role (orchestrator, architect, implementer, review_fixer, reviewers, design_reviewers), now go into that role’s prompt on every run. Things you used to repeat in every request, like “run tests with make test” or “ask before touching db/”, can be written once.
# .dev-orchestra.yaml
instructions:
orchestrator: "Ask before adding a new dependency."
implementer:
file: .dev-orchestra/implementer.md
reviewers: "Check that every public function in textkit/ has a docstring."
Alongside it came implementation.unit_tests: after_merge, which runs the units’ tests once after merging, and implementation.worktree_files, which copies git-ignored files (such as .env.test) into each unit’s worktree. See the per-role instructions post for how to use them.
Questions before the design (1.1.0)
With design.ask_questions set to auto or true, dev-orchestra now asks you questions about the requirements before the plan is written. The orchestrator asks the questions it noticed itself, then the architect asks the ones it found by reading the code. The answers are collected in decisions.md and reflected in the plan’s ## Decisions.
dev-orchestra config set design.ask_questions auto
It is off (false) by default, and while it stays off nothing changes from 1.0.0. The number of question rounds is capped by design.max_question_rounds (default 2).
Configurable progress reports (1.1.2)
The new progress settings decide how often the orchestrator reports during a long run.
| Setting | Default | What it does |
|---|---|---|
progress.updates | auto | true always runs architect runs and reviews in the background and reports on them. false keeps only the “may be stuck” notice |
progress.interval_seconds | 180 | How often to report (30 to 3600 seconds). Also the default wait of jobs wait |
progress.quiet_notice_seconds | 600 | With no tool activity for this many seconds, it says may be stuck. 0 turns it off |
The “may be stuck” notice only informs; it never cancels the run.
Changes you may need to act on
- If you capture its output on Windows (1.2.0). Output to a pipe or a file is now written in UTF-8. Japanese read by the agent is no longer garbled, but capturing it in PowerShell, as in
$x = dev-orchestra ..., now garbles it there instead. Set[Console]::OutputEncodingto UTF-8, or setPYTHONIOENCODING=cp932to get the old output - The default wait of
jobs wait(1.1.2). Without--timeout, it now waits 180 seconds (progress.interval_seconds) instead of 60 - The wording of
config validate(1.1.2). Messages for settings that accept null now sayor null. The accepted values haven’t changed, but a script that matches the message text fromconfig validate --jsonordoctor --jsonneeds updating - Your own adapters.
Provider.worktree_files(1.2.0) andProvider.file_read_tools(1.2.1) were added. Both have defaults, so nothing needs to change
Smaller changes and bug fixes
- A work unit whose run is gone is now recorded as failed as soon as
units statusorrun implementer --unitruns (no need to rununits cleanfirst) - A file to be copied into a unit’s worktree that goes through a link, or isn’t a regular file, is now skipped with a
note: - The workflow guidance now asks for shorter plans, splits a plan with more than four steps into work units, and sends small jobs to the
lighttier (to keep costs down; the CLI’s behavior is unchanged) - On Windows, a file being replaced could vanish for an instant to a reader, so a running job or its state could be read as missing. Fixed
- On Windows,
hooks install/hooks uninstallcouldn’t write asettings.jsonthat Claude Code or an editor had open. They now retry reviewer set --rolenow drops the old role’s relevance rule when the role changes and says so (as the setup wizard does)- Antigravity CLI (agy) 1.4.7 reads files with
read_file, so the tool activity display and the live checks now accept it as well asview_file - The live check script (
scripts/smoke_live.py) no longer crashes when printing results on a Japanese Windows console - The README now opens with an animated example run
Stabilization
As usual, there was internal reorganization for stability, such as splitting large files by responsibility, along with added and tidied tests. CI now runs the tests split into parts in parallel. Nothing changes from a user’s point of view.
How to update
How you update depends on your CLI. Follow the steps in the update post with the new version’s tag (v1.2.1). After updating, it’s worth running dev-orchestra doctor once.
Summary
- Work units (1.2.0): split a plan, and run the independent parts side by side in worktrees
- Per-role instructions (1.2.1): instructions under
instructionsgo into the prompt on every run. Plus a setting to run the units’ tests after merging - Questions before the design (1.1.0):
design.ask_questionschecks the requirements before the plan - Progress reports (1.1.2):
progresssets the interval and the “may be stuck” notice - If you capture its output on Windows, watch out for the switch to UTF-8
GitHub: istb16/dev-orchestra (a star is always appreciated)
Related Posts
Updating dev-orchestra (Claude Code / Codex / Antigravity)
I actually updated dev-orchestra from 1.0.0 to 1.1.1 in each of Claude Code, Codex, and Antigravity. In Claude Code, claude plugin update alone did nothing; the marketplace had to be refreshed first. I cover how to check your version, the steps for each CLI, and what to check after updating.
I tried dev-orchestra in Antigravity
I installed dev-orchestra in Antigravity too. It works fine as the place you talk to, but handing design and review to the Antigravity CLI (agy) is limited. Here is what works, what doesn't, and how I recommend using it.
I Measured dev-orchestra: Time per Request, and Findings by Number of Reviewers
With dev-orchestra 1.2.1, I made one small feature request and measured how long it took (about 6 minutes, not counting my approval) and how many findings were reported and accepted with 1, 2, and 4 reviewers. More reviewers meant more accepted findings, but the extra ones were about tests.