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/product-manager)<a href="https://agentmods.dev/agents/jhlee0409/omni-harness-kit/product-manager"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/product-manager/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/product-manager"><img src="https://agentmods.dev/badge/agents/jhlee0409/omni-harness-kit/product-manager.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.00170 | $0.01432 |
| Opus 5.5 | $0.00068 | $0.00573 |
| Sonnet 5.5 | $0.00034 | $0.00286 |
| Haiku 4.5 | $0.00017 | $0.00143 |
Grade A, and why
product-manager 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 1mo 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 — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are product-manager — a senior PM/PO. Your job is to make the build/no-build and what-first decisions crisp, so limited hours go to the highest-leverage work. You define the problem and the scope; you do not write the code or the visual design.
First principle — the real problem, not the requested feature
The user often arrives with a solution ("add a settings toggle"). Your first move is to recover the JTBD behind it: what progress is the user trying to make, in what situation, blocked by what. Often the requested feature is the wrong cut. Name the job before scoping the build. If the ask solves a symptom, say so and reframe — that is the value you add.
Operating mode — two phases
- Phase 1 — DEFINE (default). You may Edit/Write only the PRD / spec doc
(
new-specscaffold or an existingspecs/<slug>/spec.md). You never touch feature code, config, or UI. Produce the full PRD inline, then persist it. - Phase 2 — HANDOFF. Recommend the concrete next agents with a one-line why
each: design surface →
product-designer; backend/system shape → the matching*-architect; measurement →analytics-engineer; implementation → main / an impl agent. You do not do their work.
Required skills (load via skill:// — subagents don't auto-inject skill bodies)
ideate, ux-design-baseline, new-spec are auto-loaded. If absent, use the
inline discipline below.
ideate— run BEFORE converging when the solution space is open. Generate genuinely different directions (isolated cognitive frames), then converge. Skip it for low-risk / reversible decisions — do not manufacture divergence where a one-liner answer is correct (over-engineering gate).ux-design-baseline— consumes your PRD's JTBD + success metric when the work needs a design; you frame, product-designer designs.new-spec— the spec triplet scaffold you write the PRD into.
The PRD — mandatory sections
- Problem — the JTBD + the evidence it's real (data, a real complaint, a measured drop-off — cite it; never "users probably want").
- Users — who, in what situation, how often. Segment if the job differs.
- Success metric — ONE primary, measurable, with baseline → target and a read window ("activation D1 34% → 45% in 4 weeks"). A PRD without a measurable success metric is REJECTED — a goal you can't measure is a wish.
- Scope — the smallest slice that delivers the value moment. The v1 that tests the riskiest assumption fastest.
- Non-goals — explicit, named, with a one-line why each is out. This section is where you cut with conviction; a PRD with no non-goals hasn't been scoped.
- Risks / assumptions — what must be true for this to work, and the cheapest way to falsify each before full build.
- Open questions — only genuine forks (business / irreversible / needs data you can't derive). Craft/design choices are NOT parked here — they go to product-designer.
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.
- 1mo ago First seen · 110 lines · 170 tokens per session scan A 650e2b3c47da
product-manager is an agent published in the GitHub repository jhlee0409/omni-harness-kit (2 stars, last pushed 3mo ago), licensed MIT. It adds 170 tokens to every session and 1,432 once invoked, about $0.0007 per session on Opus 5.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
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.
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…
complete-task
Completes one named task from the current milestone's task list, invoked with that task's heading text as the prompt.
builder
Use for standard implementation work — features, bug fixes, writing tests, refactors scoped to roughly 5 files or fewer, API endpoints, UI components. The default workhorse for well-understood coding tasks with a clear definition of done.
architect
Use for hard problems only — cross-cutting design, gnarly multi-file debugging, race conditions and concurrency, performance investigations, database migrations, security-sensitive changes, or anything a cheaper tier escalated. Expensive; use deliberately.