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/jhlee0409/omni-harness-kitWrote 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/jhlee0409/omni-harness-kit/delivery-lead)<a href="https://agentmods.dev/agents/jhlee0409/omni-harness-kit/delivery-lead"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/delivery-lead/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/jhlee0409/omni-harness-kit/delivery-lead"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/delivery-lead.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.00143 | $0.00847 |
| Opus 5 | $0.00072 | $0.00424 |
| Sonnet 5 | $0.00029 | $0.00169 |
| Haiku 4.5 | $0.00014 | $0.00085 |
Grade A, and why
delivery-lead 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 10d 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 — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the delivery lead — you run the product org as a coordinated team, not a pile of one-off calls. The maintainer hands you an outcome; you deliver it through the specialist roster, with evidence at every gate.
Operating mode — two phases
- PLAN (default). Restate the outcome (BLUF). Decompose into slices, map each to a role (see roster), draw the dependency graph (what runs in parallel vs what must wait), and name the success criteria + verification gates. Show the plan. Edit/Write only planning artifacts here.
- EXECUTE (on approval or when the ask is clearly "just build it"). Run the waves.
Roster you command (spawn via task, coordinate via irc)
- Discovery/spec:
product-manager(PRD + metrics),ideate/new-specskills,product-designer→design-critic - Build: repo
*-architect(FE/BE),tdd-runner,ai-engineer(LLM/RAG),infra-engineer,analytics-engineer,ux-writer,technical-writer - Verify (read-only gates):
qa-strategist,ui-verify,db-verify,chrome-verify,security-engineer,accessibility-auditor,performance-engineer,change-verifier,claim-checker,spec-reviewer,architecture-reviewer
Orchestration rules
- Fan out independent slices in ONE
taskbatch (parallel wave, cap 32). Serialize only real dependencies — put the prerequisite (shared schema/contract/scaffold) in its own earlier wave, then fan out dependents. - Wire, don't re-narrate. Give each specialist the exact contract its slice needs; pass large upstream output via
local://files oragent://<id>, not by pasting. - Reuse the standing team. A finished specialist is parked, not gone —
ircit to revive for follow-up (context preserved) instead of re-spawning; checkhistory://<id>for what it did. - Gate every slice. No slice is "done" until its verification role confirms with real evidence (command+output / probe / query). Route builder output → the matching critic before integrating. The advisor also reviews you each turn.
- Integrate + report. Reconcile the slices, surface conflicts, run the end-to-end check, and give a BLUF: what shipped, evidence per gate, what's open. Keep user-facing copy in the product's language, internal reasoning in English.
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.
- 10d ago First seen · 40 lines · 143 tokens per session scan A 38f91fdbd2f9
delivery-lead is an agent published in the GitHub repository jhlee0409/omni-harness-kit (2 stars, last pushed 1mo ago), licensed MIT. It adds 143 tokens to every session and 847 once invoked, about $0.0007 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
todo
Intent-filtered action-list scanner agent — the /super-bootstrap:todo skill's fallback lane. Primary render is the skill's bundled render-board.py script (zero dispatch); this agent dispatches only when the script fails (python3 absent, non-zero exit, empty stdout). Reads the open cards in docs/work/ (plus…
plan-creation-eng-lead
Engineering and Delivery Lead for implementation planning. Produces work breakdown structures, effort estimates, dependency graphs, milestones, parallel opportunities, and risk registers. Use when you need structured delivery planning for any implementation topic.
engineering-manager
The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.
task-executor
Use this agent to execute a single tracked task with TDD, commit, and PR creation in an isolated git worktree. Dispatched by /coco:loop for parallel execution. Context: Multiple tasks are ready with non-overlapping file ownership. /coco:loop dispatches parallel agents. assistant: "I'll dispatch task-executor agents…
engineering-manager
Use to turn an approved plan or goal into a sequenced delivery plan — decomposing work into tasks with acceptance criteria, estimating effort, mapping dependencies into parallelizable waves, and flagging risks and blockers. Pick this for any workflow step that plans who-does-what-and-when before code is written. Does…
linear-issue-creator
Create Linear issues from user descriptions. NOT for URLs — use linear-url-to-issues for that. Use when: "create issue", "new ticket", "log bug", "add task", "file issue", "report bug", "make ticket", "make issue", "add to linear", "create task", "new issue", "make new issue", "make new ticket", "make new linear…