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 skills/ariaxhan/kernel-claude/orchestrationnpx skills add ariaxhan/kernel-claude --skill orchestrationgit clone --depth 1 https://github.com/ariaxhan/kernel-claudeWrote 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/skills/ariaxhan/kernel-claude/orchestration)<a href="https://agentmods.dev/skills/ariaxhan/kernel-claude/orchestration"><img src="https://agentmods.dev/badge/skills/ariaxhan/kernel-claude/orchestration.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.00047 | $0.01253 |
| Opus 5 | $0.00023 | $0.00626 |
| Sonnet 5 | $0.00009 | $0.00251 |
| Haiku 4.5 | $0.00005 | $0.00125 |
Grade A, and why
orchestration scanned grade A with 1 finding 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
prove its own work (test invocation, grep, curl), plus expected output. How it starts
The opening of the file, as written. The whole thing — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
<lane_contract> Every spawned lane gets ALL of these fields; a missing field is where the lane fails:
- Deliverable: the observable artifact, named exactly (file path, PR, report).
- Read-first list: the files/docs the lane must read before acting.
- Files table: exhaustive list of files it may touch (
constraints.files). No two concurrent lanes may overlap. Contract JSON:{"goal":"X","constraints":{"files":["a.sh","b.md"]},"tier":2} - Known traps, restated: gotchas relevant to this lane, inlined, not linked.
- Verification loop with exact commands: the literal commands the lane runs to prove its own work (test invocation, grep, curl), plus expected output.
- Forbidden list: what the lane must NOT do (push, touch _meta/, add deps, ...).
- Raw-data return format: counts, file lists, command output. Never narrative alone; a lane that returns only prose has returned nothing checkable. </lane_contract>
<output_integrity> Structured long-report lanes degrade silently to placeholders under load. Validate every lane return mechanically before using it: minimum-length check on required sections, placeholder detection ("TBD", "...", repeated boilerplate), counts match the claimed work. Reject-and-retry a degraded return; never synthesize over it. Pass large input pools to lanes by FILE PATH, never as an inline slice (silent truncation reads as full coverage). Each lane keeps a per-lane journal/checkpoint so a degraded final message is not the only record of what it did. </output_integrity>
<single_coordinator> One coordinator per repo at a time. Before coordinating, check for a live second session on the same working directory (stale sessions can survive as background daemons and produce split-brain: two coordinators mutating one repo in parallel). When killing a stuck session, kill its whole process pool, not just the visible pid. </single_coordinator>
<worker_model_doctrine>
Select model and effort from the lane's task shape and measured evidence, never from
role prestige. Mechanical total-spec execution with deterministic checks can use the
lowest setting proven adequate. Ambiguous judgment or a measured miss justifies more
effort; protected work requires a fresh independent verifier. The lane contract records
the requested model and effort, whether inheritance is intentional, and the escalation
condition. A prompt that says "use your judgment" is evidence of ambiguity, not a license
to choose a prestige model by role. Receipts keep requested_model and requested_effort
separate from observed_model and observed_effort. Unsupported or unexposed values are
unavailable, never inferred. Protected receipts require distinct builder_identity and
verifier_identity; the builder never grades its own protected work. The coordinator
reproduces acceptance evidence.
</worker_model_doctrine>
<fault_tolerance>
- RETRY transient failures with backoff, max 3. 2. CLASSIFY the failure before choosing recovery. 3. Never silently substitute model, effort, or provider. Use an alternative only when the contract names a pre-authorized fallback; record the original request, the failure, and the observed fallback identity separately. Otherwise stop and re-contract. 4. CHECKPOINT state to AgentDB at every boundary so a respawn resumes instead of restarting. </fault_tolerance>
<worktree_safety>
Parallel lanes (tier 2+) run in isolated git worktrees (isolation: "worktree"),
never the main worktree; failed work is discarded by deleting the worktree. Pre-spawn:
working tree clean or stashed; each lane's constraints.files disjoint from all
active lanes. Post-agent validation: read the lane's checkpoint, then
git diff --name-only {base}..{lane_branch}; every changed file MUST appear in
constraints.files, and an out-of-scope file means reject, do not merge, re-contract.
Tier 1 skips worktrees (unnecessary overhead).
</worktree_safety>
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 104 lines · 47 tokens per session scan A b9303ec21fb1
orchestration is a skill published in the GitHub repository ariaxhan/kernel-claude (12 stars, last pushed today), licensed MIT. It adds 47 tokens to every session and 1,253 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
prolong
Recover and use durable coding-session history from PRO-LONG's local append-only log. Use on long-running coding tasks, after context compaction or session resume, when reconstructing prior decisions or tool results, or before repeating work that may already have been attempted.
lemmalog
Externalize working memory and logical state into the lemmalog Datalog engine (MCP). Use for ANY multi-step task where state should outlive one context window or span agents: long investigations, debugging sessions, audits, multi-agent searches, systematic explorations, planning with many interdependent constraints…
causal-memory
Causal memory for agents — install/setup the causal-memory MCP server, then record decisions/outcomes and recall them before acting. Trigger when the user asks to install or set up causal-memory/agent memory, when causal-memory MCP tools are available and the agent faces a non-trivial decision (architecture, debugging…
a0-create-plugin
Create, extend, or modify Agent Zero plugins. Follows strict full-stack conventions (usr/plugins, plugin.yaml, Store Gating, AgentContext, plugin settings). Use for UI hooks, API handlers, lifecycle extensions, or plugin settings UI.
a0-review-plugin
Full audit of Agent Zero plugins in usr/plugins/. Reviews manifest validity, directory structure, code patterns (Store Gating, notifications, imports), security, and duplicate detection against the community index. Use when asked to review, audit, validate, or check an existing plugin before using or contributing it.
create-skill
Wizard for creating new Agent Zero skills. Guides users through creating well-structured SKILL.md files. Use when users want to create custom skills.