If you already run claude-code, cline, codex, or opencode
The management layer above your coding agent.
You already know what a CLI agent can do in one session. aidd sits above it: dependency-ordered backlogs, unattended multi-iteration runs, gates that decide what counts as done, and a run ledger in your repo - driving the same agent you use today.
What your CLI doesn't do
A session is one repo, one context window, one conversation. The agent decides for itself when it's finished, and you've seen how that goes: "I've completed the implementation" over a diff with a stubbed function and a test that asserts nothing. When the session ends, the transcript is the only record. CLAUDE.md gives an agent standing instructions inside one repo, but nothing looks across your projects, orders the work, or enforces completion.
That's not a knock on the agent. It's an execution engine. It's just also been doing its own project management, and it's bad at that job.
What aidd is
aidd is a local orchestrator - a Bun/TypeScript CLI plus a local web panel -
that launches your agent as the execution engine. A spec becomes features with
acceptance criteria and dependencies under .aidd/features/. A run
loops: pick the next eligible feature, compile the prompt, invoke the CLI once,
check the result. Repeat until the backlog empties or the run hits its iteration
or wall-clock limit.
Plan
Spec to dependency-ordered features, each with acceptance criteria.
Build
Iterations, one CLI invocation each, watchable live from the panel.
Verify
Tests, typecheck, lint, and browser-level checks gate every feature.
Record
Run ledger, per-iteration logs, and audit reports as plain files.
A feature the agent claims is done but that fails a gate stays open and goes back around the loop. The model doesn't get a vote.
What you get on top
Your CLI stays
claude-code, cline, codex, opencode, kilocode, grok, any OpenAI-compatible API, or local Ollama / LM Studio. The CLI is a per-run setting, so comparing agents on the same backlog is a dropdown.
Receipts in the repo
.aidd/runs.jsonl, per-iteration logs, feature status, and
audit reports live next to the code as plain files. Greppable, diffable,
and not hostage to aidd - the format is documented.
Audits with evidence
Security, architecture, performance, and integration audits (among ~45) where every finding must cite current-code evidence - file and line - before it lands in the backlog as work.
A director for the fleet
Discovers every project under the roots you configure, scans them in cycles, and proposes prioritized work. Accept a suggestion and it launches a run. Cycles can run on a schedule, and suggestion auto-launch is available: bounded, and off by default.
Recipes, not re-prompting
Multi-step workflows - review, fix, verify - saved as JSON files and rerun on any project, from the panel or on a schedule.
MCP and Telegram
An MCP server (bun run start -- --mcp, alongside the
running panel) exposes it to other agent sessions, and a Telegram bridge
puts the fleet Director in your pocket - ask it what's going on from
your phone. Both are included with aidd.
What it isn't
It doesn't replace interactive sessions - you'll still drop into claude-code
directly for exploratory work, and aidd stays out of the way when you do. It's
not a cloud platform; there's no hosted anything. It is opinionated about
project state: work is tracked as features in .aidd/, and coding
runs select from that backlog rather than freeform prompts - a one-off
instruction is its own mode (--prompt), not the default. Windows 11
with PowerShell 7 is the first-class platform; Linux runs the full quality gate
in CI, and macOS is expected to work but is checked by hand. There are no
prebuilt binaries - aidd ships as source on every platform and runs on Bun.
Your keys, your machine, your plan. Runs use the subscription or API keys you already have, bounded per run by iteration and wall-clock limits, with cost and token ceilings you set surfacing as warnings in the run log. aidd has no hosted control plane or user account; it sends no telemetry and does not phone home. Network traffic comes only from providers or integrations you configure, or downloads you initiate.