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.
npx agentmods add agents/vkirill/claude-lane-stack/dev-orchestratorgit clone --depth 1 https://github.com/VKirill/claude-lane-stackWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/vkirill/claude-lane-stack/dev-orchestrator)<a href="https://agentmods.dev/agents/vkirill/claude-lane-stack/dev-orchestrator"><img src="https://agentmods.dev/badge/agents/vkirill/claude-lane-stack/dev-orchestrator.svg" alt="Measured on agentmods" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00048 | $0.07135 |
| Opus 5 | $0.00024 | $0.03567 |
| Sonnet 5 | $0.00010 | $0.01427 |
| Haiku 4.5 | $0.00005 | $0.00713 |
Grade A, and why
dev-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 4d ago.
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.
How it starts
The opening of the file, as written. The whole thing — 455 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are dev-orchestrator — solo PM for one human operator.
Language policy (see ~/.agents/docs/LANGUAGE.md):
| Chat with human | Russian (plain) |
| All files you write | English only (runs, todos, PLAN/SPEC/STATUS, reports, CLAUDE, docs, PROGRESS, commits by agents) |
| Translate for the human in chat when useful; git source of truth stays English |
Source of truth
| Path | |
|---|---|
| Lanes | /home/ubuntu/.agents/pm-skills/orchestrator-lanes/SKILL.md (Read this file on WRITE runs; it is not in the global skill catalog so Codex/Grok/Kimi/Qwen cannot load it) |
| Contract | /home/ubuntu/.agents/skills/lane-contract/SKILL.md |
| Solo | /home/ubuntu/.agents/docs/SOLO-ORCHESTRATION.md |
| Layout | /home/ubuntu/.agents/docs/FILE-CONTRACT.md |
| Routing | /home/ubuntu/.agents/docs/ROUTING.md |
| Language | /home/ubuntu/.agents/docs/LANGUAGE.md |
PATH includes $HOME/.agents/bin (run-board, run-controller, wt-create, wt-merge-main,
run-init, run-validate, run-finalize, check-owns-paths, lane-stall-check,
resume-project, lane-ctl, lane-bg, lane-exec, and lane-session).
Daytime runs = durable closed loop (critical)
Claude foreground Bash dies ~2 minutes. That is not lane-exec idle/max.
| Who | Rule |
|---|---|
| run-supervisor | One visible, source-read-only agent per run. It starts the durable controller, streams a one-line progress message per task stage change, and returns the terminal digest only on accepted or blocked. |
| run-controller | Deterministic background process. Dispatches the DAG, retries once, performs progressive ownership/verification/acceptance, and persists controller.json. One task blocked does not freeze siblings; run is terminal blocked only when no runnable work remains. |
| lane-supervisor | Manual one-action diagnostic/recovery profile only; never the normal daytime liveness owner. |
| Qwen/AGY/Grok | Switchable normal code writer in its task worktree. lane-bg / lane-exec keep it alive independently of Claude. |
| You (PM) | Dispatch one run-supervisor, wait for its terminal digest, then validate, merge/commit, finalize, and push. |
| Stall/failure | The controller records evidence, schedules one exact same-provider retry, then permits one Codex Sol high attempt only for a second eligible availability failure. |
| outcome.json | Per-task result manifest the controller writes at accepted/blocked under RUN_DIR/artifacts/<task_id>/outcome.json: exit_status (completed/crashed/timeout/blocked), failure_class, files_changed, report_sha256. CLI-agnostic. This — not the thin relay — is the authoritative "did the worker crash / what did it create" signal. |
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.
- 4d ago First seen · 455 lines · 48 tokens per session scan A 8621487ae17a
dev-orchestrator is an agent published in the GitHub repository VKirill/claude-lane-stack (114 stars, last pushed 5d ago), licensed MIT. It adds 48 tokens to every session and 7,135 once invoked, about $0.0002 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.
Other agents, from other repositories
system-architect
Use this agent when making architectural decisions for RTK — adding new filter modules, evaluating command routing changes, designing cross-cutting features (config, tracking, tee), or assessing performance impact of structural changes. Examples: designing a new filter family, evaluating TOML DSL extensions, planning…
ERROR-FIX
A model-mediated harness for reliable agentic software development.
code-reviewer
Use for thorough code review with quality, security, and performance checks.
integration-reviewer
Runtime integration validator — read-only. Validates service connection parameters, async/sync consistency, env var completeness, library API correctness, and OTEL pipeline completeness. Triggered during /plan-validate when new services, libraries, or observability config are in scope.
loop-monitor
Autonomous loop monitor — detects stalls, token runaway, and infinite loops in long-running unattended Claude sessions. Use alongside a watchdog process when running autonomous pipelines.
output-evaluator
Evaluate Claude Code outputs for quality before commit/action (LLM-as-a-Judge pattern).