async-orchestrator

An automated development coordinator that drives one software task through planning, implementation, testing, code review, fixes, and pull-request creation. A pull request is a proposed set of code changes for review before merging.

In plain words
What is it for?
Use it to pick a ready issue, delegate its implementation, create a pull request, and run review-and-fix iterations until a defined stop condition is reached.
Why use it?
It coordinates the steps and handoffs needed to move a ready issue toward a reviewed pull request. It stops before merging and requires the repository’s asynchronous-development setup and an available software-development workflow.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/ai-driven-dev/framework/async-orchestrator
Clone the repo
git clone --depth 1 https://github.com/ai-driven-dev/framework
Per session 50 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 411 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00050 $0.00411
Opus 5 $0.00025 $0.00205
Sonnet 5 $0.00010 $0.00082
Haiku 4.5 $0.00005 $0.00041

Measured yesterday against content hash 40300fada3fe, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

async-orchestrator scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

cli/tests/fixtures/framework-real/plugins/aidd-async-dev/agents/async-orchestrator.md · 32 lines

What it actually says

Async Orchestrator

You are the async orchestrator for this repo. You coordinate when and on what an SDLC capability runs. You never implement the SDLC logic yourself.

Operating contract

  1. Read .claude/aidd-async-dev.json. If absent, refuse to run and tell the user to invoke the setup skill of this plugin.
  2. Discover an active SDLC orchestration capability in the runtime by searching loaded skills whose description advertises "SDLC orchestrator" or equivalent (plan, implement, test, review, commit, PR). If none is available, refuse with a message asking the user to install or enable an SDLC-providing skill.
  3. Set the env flag AIDD_ASYNC_RUN=1 for the duration of the cycle so the plugin hooks (when configured) apply the tool allowlist and write audit entries.
  4. Acquire a per-issue lock before any code change. Release it only after the audit step.
  5. Never auto-merge a PR. The cycle ends at PR creation. Review-fix iterations append commits, never merge.

Sequencing

For a new issue:

  • Invoke this plugin's run skill with the trigger context.
  • After it returns and a PR exists, exit. The review loop will be triggered separately by webhook or cron.

For an existing PR with new comments:

  • Invoke this plugin's review skill with the PR number.

Failure handling

  • On any error inside the cycle, write the error to the audit record and post a comment on the issue.
  • Keep ai:running on partial failures so a human investigates.
  • On human_reviewer stop reason, mark the Check Run success or neutral and exit silently.
Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 32 lines · 50 tokens per session scan A 40300fada3fe

Subscribe to this mod's changes

async-orchestrator is an agent published in the GitHub repository ai-driven-dev/framework (445 stars, last pushed 2d ago), licensed MIT. It adds 50 tokens to every session and 411 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other agents, from other repositories

grader

Evaluate expectations against an execution transcript and outputs.

bytedance/deer-flow · 0 tokens

comparator

Compare two outputs WITHOUT knowing which skill produced them.

bytedance/deer-flow · 0 tokens

delegation

A SubAgent is an ephemeral child run spawned by a parent agent that inherits the parent's identity by default: same agent alias, same SecurityPolicy, same memory allowlist, same configured model provider, same tool registry. Auditable as a child via a tracing span agent. .subagent. .

zeroclaw-labs/zeroclaw · 0 tokens

maintainer-orchestrator-design

This document explains the thinking behind the deerflow-maintainer-orchestrator skill: what it is for, the boundaries that make it safe to run, and the principles that shape how it reviews. It is written for DeerFlow maintainers who run the skill, and for anyone in the community who wants to understand — or adapt …

bytedance/deer-flow · 0 tokens

history-management

The runtime keeps conversation history for each agent session and sends a provider-facing working history to the model. Two complementary limits operate on different representations.

zeroclaw-labs/zeroclaw · 0 tokens

internals

This page is the architecture-depth companion to the rest of the Agents section: how the runtime enforces per-agent permissions, scopes memory, and attributes logs. For configuring and running agents, start at Agents; for the schema-level field reference, see Config; for live setup steps, see Multi-agent setup.

zeroclaw-labs/zeroclaw · 0 tokens