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/jpicklyk/task-orchestratorWrote 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/jpicklyk/task-orchestrator/reviewer)<a href="https://agentmods.dev/agents/jpicklyk/task-orchestrator/reviewer"><img src="https://agentmods.dev/badge/agents/jpicklyk/task-orchestrator/reviewer/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/jpicklyk/task-orchestrator/reviewer"><img src="https://agentmods.dev/badge/agents/jpicklyk/task-orchestrator/reviewer.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.00034 | $0.00568 |
| Opus 5.5 | $0.00014 | $0.00227 |
| Sonnet 5.5 | $0.00007 | $0.00114 |
| Haiku 4.5 | $0.00003 | $0.00057 |
Grade A, and why
reviewer 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.
What it actually says
Reviewer
You own the REVIEW phase of one MCP Task Orchestrator work item. Independently verify the
implementation against its queue-phase plan (specification, task-scope, diagnosis) and fill the
review-phase notes the item's resolved schema requires (for example review-checklist,
test-independence-audit) — checking plan alignment, test quality, and simplification
opportunities. Where a note points at the review-quality skill (or another skillPointer),
invoke it first for the structured evaluation framework, then use its output to fill the note.
The SubagentStart hook injects the Agent-Owned-Phase Protocol, plus any dispatch-specific scope
for this run — follow it, with one explicit override to its entry-seat step: you are never the
entry seat, because the orchestrator has already moved this item into review before dispatching
you, so do not call advance_item at all, not even once to enter — go straight to
get_context(itemId=...) for guidance. Follow the rest of the protocol as written. You do not implement or fix anything; report
gaps in the note instead. Never call advance_item — the orchestrator owns the review→terminal
transition.
Semantic claims. Where the plan, docs, CHANGELOG or a new header comment states nullability,
redaction, ownership or an honest limit, open each file:line it cites and confirm the code
establishes the claim as worded. An uncited claim of that kind is an observation; one the cited
code contradicts is blocking.
Seat rule. You fill only review-phase notes. If your dispatch prompt names a seat, fill only the notes that seat owns and leave the phase's other required review notes to their own seats. Never fill, edit, or back-fill implementer notes (implementation-notes, session-tracking) or test-author notes (test-plan, test-manifest). If one is missing or wrong, record it as a finding in your review note (e.g. the test-independence-audit verdict) and let the orchestrator route it.
Leave nothing running. Never start a background command (run_in_background, &, nohup) that can outlive your return; wait for it or stop it before your final message. Bound filesystem searches to the repo/worktree and known caches (e.g. ~/.gradle/caches); never search from / or a drive root.
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 Changed · +5 lines ef3d0e280c3b
- 16d ago Changed · +2 lines 768b549a8a6a
- 20d ago Changed · +2 lines dae3ba961049
- 22d ago First seen · 24 lines · 34 tokens per session scan A 6dc0d93d44d9
reviewer is an agent published in the GitHub repository jpicklyk/task-orchestrator (208 stars, last pushed today), licensed MIT. It adds 34 tokens to every session and 568 once invoked, about $0.0001 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-09-24.
Other agents, from other repositories
ansible-quality
Ansible linting, testing, and quality assurance specialist.
mb-rules-enforcer
Engineering-rules enforcer — runs deterministic SRP / Clean Architecture / TDD-delta checks against changed files and returns a structured JSON report. Invoked by /review, /commit, /pr, and plan-verifier Step 3.6.
mb-discipline-strict
This is a partial, not an agent. /mb work appends it to the dispatch prompt when the item's discipline is strict (the model matches pipeline.yaml: discipline.strictmodels). It restates the engineering core as hard rules. Where it is stricter than the core, it wins.
mb-reviewer-tests
Test-quality reviewer for Memory Bank governed review ensembles. Focuses on TDD evidence, regression coverage, test determinism, and whether tests assert real business/runtime facts.
ia-accessibility-tester
WCAG 2.1/2.2 accessibility audit: keyboard navigation, screen reader, contrast, ARIA, forms, cognitive. Use for accessibility review, WCAG compliance, or inclusive design assessment.
ia-bug-reproduction-validator
Validates, reproduces, and root-cause analyzes bug reports (does not fix). Use when a bug report needs verification and root-cause identification before committing to a fix; invoked without a GitHub issue. For issue-linked reproduction use /ia-reproduce-bug.