← ClaudeAtlas

concertino-fleet-driverlisted

Drive multiple concertino orchestrator runs concurrently from directly within a Claude Code session, without the concertino watch TUI. Use when a user asks to work a batch of tickets, run an epic end-to-end, or otherwise wants several concertino deliveries coordinated in parallel by the current session rather than one at a time or via the dashboard.
matto00/concertino · ★ 2 · AI & Automation · score 71
Install: claude install-skill matto00/concertino
Coordinate several concertino ticket-delivery runs at once as their **driver** — the layer above the orchestrator that `concertino watch`'s TUI (fleet view, launch pad, `NEEDS YOU` queue) plays for a human operator, replayed here as Claude Code session discipline instead: `Agent` calls instead of tmux panes, `SendMessage` instead of approve/deny keys, `gh pr checks`/`gh pr merge` yourself instead of a merge-confirmation screen. Every rule below exists because skipping it caused a real, specific incident in production driving (helio, 2026-08-16/17 — one session, seven tickets, three near-misses; and 2026-09-07/09 — two nights, five lanes, 19 merged PRs, which added §§11-15). This is not theoretical hardening; it is what actually broke. --- ## 1. Concurrency: hold a target count, never force a slot Default to 2 concurrent orchestrator runs unless the user specifies otherwise. When one finishes, dispatch the next queued ticket to refill the slot — but **do not dispatch just to keep the count full** if every remaining candidate has a concrete reason to wait (a migration-number claim it would collide with, a file it would conflict with on a still-open sibling PR). Holding at N-1 for a while is cheaper than resolving an avoidable merge conflict later. When a user explicitly overrides this ("launch it anyway, in parallel"), follow the instruction, but brief the new orchestrator on the specific collision risk before it starts (see §4) rather than launching it blind. ## 2. Relay