Maestro Orchestration Platform
Multi-agent development orchestration for Gemini CLI, Claude Code, Codex, and Qwen Code: 39 specialists, parallel subagents, persistent sessions, and built-in review, security, SEO, accessibility, and compliance tooling.
README states it follows host permission/confirmation models, requires no committed secrets, and keeps state within MAESTRO_STATE_DIR; integration tests prove initialize_workspace rejects plugin-cache paths. But these are assertions plus partial tests; no comprehensive audit of parallel subagents/hooks, so least_privilege, user_confirmation, data_flow, and sensitive_data score 2. Dependency surface is tiny (one devDep, c8) — deduction: no pinned supply-chain attestation. External effects are bounded and settings files are explicitly not auto-edited: 2. Rollback relies only on archive/resume with no explicit undo/recovery: 1. Attribution is self-declared author metadata only; publisher unverified: 1.
CI's generator-check enforces zero drift between src/ and generated artifacts and runs the full suite — strong self-consistency: 3. Near-zero runtime dependencies (Node built-in test runner) — availability risk minimal: 3. Integration tests show structured, sequenced error messages (e.g., a NOT_FOUND naming both endpoints when the design doc never materialized): 3.
README documents command surfaces, install steps, and config per runtime, and distinguishes Express vs Standard workflows: 3. Command names deliberately avoid host-reserved names (review/debug/resume) with tests enforcing this — trigger precision: 3. Four runtimes each have dedicated runtime docs: 3. However, boundaries of the 39 specialists are essentially unexpanded in the given files — capability_boundaries: 2.
Clean doc architecture (overview/architecture/usage/flow/runtime-*), per-runtime install instructions incl. local dev, and a src-of-truth pipeline enforced by CI: all 3. Naming stability is test-enforced against host collisions: 3. Full Apache-2.0 text: 3. EXAMPLES.md and CHANGELOG.md are referenced/listed but absent from evidence, so examples_and_faq and versioning_changelog score 2. No known-limitations section: 1. SECURITY.md gives supported versions and response timelines but governance rests on a single maintainer: 2.
Output paths and success criteria (approved plan, phase reports, Critical/Major blocking) are concrete and checkable — output_usability: 3. Multi-runtime orchestration plus quality gates offers real differentiation, but the 39-specialist and audit-entrypoint gains are assertion-backed only — marginal_value and cost_benefit: 2.
Core claims (generator consistency, error semantics, naming avoidance, workspace rejection) trace to tests: 2. Heavy references to docs/EXAMPLES whose contents are not in evidence — cross_source_corroboration: 1. Claims and inferences are largely separated (e.g., explicit 'does not edit settings.'): 2.
- This is a static review; no install or orchestration was executed, so the real behavior of the 39 specialists and audit entrypoints is unverified by run.
- EXAMPLES.md, CHANGELOG.md, and runtime docs are referenced but absent from the evidence — verify them before adoption.
- Rollback relies only on archive/resume; there is no explicit undo for changed code — use alongside version control.
- Parallel subagents and hooks rely on the host sandbox; in sensitive repos set MAESTRO_DISABLED_AGENTS and run security-audit first.
- Publisher identity is unverified and the project appears single-maintainer; long-term maintenance is uncertain.
What does this agent do, and when should you use it?
Maestro (josstei/maestro-orchestrate, Apache-2.0, v1.6.4) is a multi-agent development orchestration platform that generates runtime artifacts for four CLIs from a single canonical src/ tree. It ships 39 specialist agents, an Express path for simple work, and a four-phase Standard workflow (Design, Plan, Execute, Complete) for medium and complex tasks, plus standalone review, debug, security audit, performance, SEO, accessibility, and compliance entrypoints. Session state persists under MAESTRO_STATE_DIR (default docs/maestro/), and failed phases record a blocker and next required action instead of continuing silently. It operates within the host runtime's permission and confirmation model and requires no committed secrets or long-lived credentials.
An orchestration entrypoint (e.g. /maestro:orchestrate, $maestro:orchestrate, or /orchestrate) takes a task description; Maestro classifies the task, chooses Express or Standard workflow, asks required design questions, produces an implementation plan when needed, delegates execution to specialist subagents, runs a quality gate, and writes session state, plans, phase reports, and archives to docs/maestro/. The Standard workflow requires an approved plan, completed phase reports, and blocks final review on unresolved Critical or Major findings. Standalone commands include /maestro:review, /maestro:debug, /maestro:security-audit, /maestro:perf-check, /maestro:seo-audit, /maestro:a11y-audit, and /maestro:compliance-check. The Codex runtime provides plugin skills with spawn_agent and launches an MCP server; Qwen Code uses a Gemini-CLI-compatible extension reading QWEN.md.
- A full-stack developer bootstraps a REST API end-to-end — design, implementation, and review — from one orchestration command
- A team runs /maestro:review on staged changes before committing to catch correctness, regressions, security, and missing tests
- A security engineer runs /maestro:security-audit before adopting changes touching authentication, authorization, or secret handling
- A frontend team uses /maestro:a11y-audit and /maestro:seo-audit for accessibility and SEO checks
- A developer who switches between CLI tools reuses the same orchestration across Gemini CLI, Claude Code, Codex, and Qwen Code
- A project lead resumes and audits multi-phase work with /maestro:resume and session archives after an interruption
What are this agent's strengths and limitations?
- One canonical src/ tree generates artifacts for all four runtimes (Gemini CLI, Claude Code, Codex, Qwen Code), avoiding multi-tree maintenance
- 39 specialist agents plus Express/Standard workflows mean simple tasks skip ceremony while complex work gets explicit approval gates and quality gates
- Persistent, resumable session state (/maestro:resume, /maestro:archive) with blockers recorded rather than silent failures
- Built-in security audit, performance, SEO, accessibility, and compliance entrypoints, with deliberate avoidance of bare command names that collide with host built-ins on Claude/Codex
- Gemini CLI and Qwen Code require manually enabling experimental subagents (experimental.enableAgents), and command names differ per runtime, adding learning cost
- Generated directories (agents/, commands/, hooks/, etc.) are overwritten on regeneration; customization must go through src/ plus node scripts/generate.js
- Hosted on third-party CLI tools, so capabilities are constrained by those tools' maturity and experimental features
- Evidence is README-only; no third-party adoption or independent evaluation is shown
How do you install or deploy this agent?
Prerequisites: one supported runtime (Gemini CLI, Claude Code, Codex, or Qwen Code) and Node.js 20+ for the MCP server and helper scripts. Gemini/Qwen only: enable experimental subagents with experimental.enableAgents: true in ~/.gemini/settings. or ~/.qwen/settings. (Maestro does not edit these files). Install: Gemini CLI — gemini extensions install https://github.com/josstei/maestro-orchestrate; Claude Code — claude plugin marketplace add josstei/maestro-orchestrate, then claude plugin install maestro@maestro-orchestrator --scope user; Codex — codex plugin marketplace add josstei/maestro-orchestrate, start Codex, run /plugins, select Maestro, Install; Qwen Code — qwen extensions install https://github.com/josstei/maestro-orchestrate. For local development, git clone and use gemini extensions link . or qwen extensions link ., or load with claude --plugin-dir /path/to/maestro-orchestrate/claude.
How do you use this agent?
On Gemini CLI or Qwen Code: /maestro:orchestrate Build a REST API for a task management system with user authentication. Maestro classifies the task, picks Express or Standard workflow, asks design questions, delegates to specialists, and archives the session. Standalone usage: /maestro:review Review the staged changes for correctness, regressions, security, maintainability risk, and missing tests; or /maestro:security-audit Audit authentication, authorization, data exposure, secret handling, and exploitability risks. Tune behavior via MAESTRO_STATE_DIR (default docs/maestro), MAESTRO_EXECUTION_MODE (parallel/sequential/ask), MAESTRO_AUTO_ARCHIVE, MAESTRO_MAX_RETRIES, MAESTRO_MAX_CONCURRENT, and MAESTRO_DISABLED_AGENTS. Manage sessions with /maestro:resume, /maestro:status, and /maestro:archive.