This is an early release preview. You may encounter bugs.
Framework
Maestro logo
Unclaimed

development

Maestro

A local-first Rust orchestration substrate for agent-built codebases.

D 43/100 GitHub score ? This grade is derived from GitHub signals — not user votes. Open for the full breakdown.
No votes yet

01 / About

About Maestro.

maestro is a single Rust binary that gives coding agents a durable, auditable place to track and govern their work inside a repository. It targets a recurring problem with autonomous coding agents: they lose context across sessions, collide on work items, ship unverified changes, and leave no trail. maestro addresses this by storing every unit of work — what is being built, who is doing it, and the evidence it was done — as plain files under a .maestro/ directory in the repo. It is local-first with no daemon, hidden service, or cloud dependency; the agent drives the lifecycle through the CLI and the human reviews the resulting artifacts in a diff.

Work is organized as a three-level model. Cards are durable planning and governance records; a feature card owns the product contract and acts as the parent container, while other card kinds (bug, chore, progress, decision, idea, and legacy task cards) carry their own lifecycles. Tasks are the atomic executable units that dock to cards. The lifecycle is proof-gated: a feature can only be accepted once a behavior baseline is captured, tasks count as done only when a claim is backed by recorded proof, and a feature closes only when QA coverage maps every baseline scenario to evidence and the acceptance contract passes a fresh sweep. Coverage is checked rather than asserted, so a passing gate is a real signal, and decisions are recorded as cards so architectural reasoning survives context loss.

maestro also includes a cross-agent coordination layer for when multiple sessions work the same checkout — showing live sessions, non-blocking links between cards, pull-only card-scoped messages, and advisory conflict notices — plus an archive that keeps closed work searchable as memory. A rule-based (no-LLM) harness loop watches the run log and task history and surfaces self-improvement proposals when the same friction recurs, which are then worked through the same proof loop.

It installs agent skills and hooks into the repo (for Claude Code, Codex, or other CLI agents) so the agent learns the lifecycle and records its own work, and is intended to be set up and driven by the agent rather than operated by hand. It exposes an MCP server entry point and a broad CLI, and provides migration paths from an earlier TypeScript version and from a pre-card Rust layout.

02 / Discussion CREDIBILITY-GATED

Discussion · 0

Reading is open to everyone. Only verified humans or builders at GitHub B+ can post or vote — every thread carries its author's credibility.

  • No discussions yet — start the first thread.

04 / Build

Build with Maestro.

Browse the catalogue for frameworks, tools, and blueprints — each scored on real GitHub credibility.

Browse the catalogue