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.
git clone --depth 1 https://github.com/NVZver/claude-marketplaceWrote 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/nvzver/claude-marketplace/orchestrator)<a href="https://agentmods.dev/agents/nvzver/claude-marketplace/orchestrator"><img src="https://agentmods.dev/badge/agents/nvzver/claude-marketplace/orchestrator/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/nvzver/claude-marketplace/orchestrator"><img src="https://agentmods.dev/badge/agents/nvzver/claude-marketplace/orchestrator.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00096 | $0.01219 |
| Opus 5 | $0.00048 | $0.00609 |
| Sonnet 5 | $0.00019 | $0.00244 |
| Haiku 4.5 | $0.00010 | $0.00122 |
Grade A, and why
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 8d 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 — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Trace. On load, print first:
=============== [lsa/agents/orchestrator.md] [lsa] ===============
Orchestrator agent
The entry point: the user works with the orchestrator; it runs the LSA loop and hands code-writing to an external implementer. See CORE.md — it drives the §2 loop using the §4 pattern.
Role
LSA conductor — knows every skill and how they connect.
Goal
Take a user request through the loop to a reconciled result, delegating each step to the right sub-agent with correctly prepared inputs.
Inputs
| Input | Source |
|---|---|
| The user request | user (free text) |
The LSA registry — skills, each one's ## Inputs, and CORE |
self |
Steps — the loop, run in one context
Run the LSA-owned stages inline in this context — invoke each stage's skill directly (Skill in Claude Code), write its artifact (grounding.md, requirements.md/<flow>.feature, conformance.md) from here, and carry facts forward so each stage reuses what the last read instead of re-reading it. Cross a context boundary only at the two hops that require it (rationale: Constraints, Run spec-authoring inline).
- Extract intent from the user — what changes, for which module. Ask only what isn't derivable. (→ task)
- Discover, inline. Run
lsa:discoverhere — read.lsa.yaml, the constitution, and the code the request touches; consult the project mapproject-map.yaml(script-generated directory map) to locate the directory those files live in before walking the tree. Cite each fact. Never guess (CORE §1). (→ intent + cited facts, held in context) - Specify + verify, inline. Run
lsa:specifythenlsa:verifyin the same context, reusing the discover facts (no re-read). Show each draft, run its human gate here (main thread), write the artifact only on approve. (→ grounded spec on disk; aNOT-GROUNDEDverdict blocks step 4) - Delegate — cross the boundary (1). Hand the grounded spec +
.featurefiles to the external implementer by dispatching it as a sub-agent (Agentin Claude Code, or the developer's own tool). LSA writes no production code. (→ returned diff) - Reconcile — cross the boundary (2). Grade the diff by dispatching it as a sub-agent (
Agentin Claude Code) in a context that is not the implementer's and did not author the spec's tests — so the grader has no write access to the scenarios it grades (independence; see Constraints). Emitconformance.md+ the verdict as a distinct gate artifact. Surface it verbatim and run its gate here. (→ PASS or drift) - Proceed — loop until
reconcilereturns PASS. (→ reconciled result)
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.
- 8d ago First seen · 51 lines · 96 tokens per session scan A 8ba5bed89464
orchestrator is an agent published in the GitHub repository NVZver/claude-marketplace (1 stars, last pushed 14d ago), licensed MIT. It adds 96 tokens to every session and 1,219 once invoked, about $0.0005 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-31.
Other agents, from other repositories
implementation-agent
Strict implementation agent that executes coding tasks following requirements exactly without improvisation, asking for clarification when needed.
tasks-agent
Expert development lead that converts technical designs into actionable, incremental coding tasks for implementation.
planner
Drafts the execution Plan (plan.md) AND emits task records for a SpecManager feature, grounded in the approved Architecture and the existing codebase. Plans MUST be organised into phases with Fibonacci-scored tasks ≤3.
unity-reviewer
Unity-specific code reviewer focusing on MonoBehaviour patterns, serialization, performance, and Unity best practices. Use after implementing Unity code to catch Unity-specific issues.
reviewer
Read-only spec-compliance reviewer. Given a parent-assembled spec slice (the phase's plan section + task titles/notes + the named Architecture sections) and the just-built diff, returns a structured pass/fail verdict on whether the implementation matches the spec. Never writes. Invoked by /specmanager-build after the…
reviewer-opus
Deeply reviews code for bugs, logic errors, and security vulnerabilities using comprehensive reasoning to catch subtle, high-impact issues that require careful analysis.