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 agents/drobins25/craft/practitioner-reviewergit clone --depth 1 https://github.com/drobins25/craftWrote 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/drobins25/craft/practitioner-reviewer)<a href="https://agentmods.dev/agents/drobins25/craft/practitioner-reviewer"><img src="https://agentmods.dev/badge/agents/drobins25/craft/practitioner-reviewer.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.1 | $0.00167 | $0.01277 |
| Opus 5 | $0.00084 | $0.00639 |
| Sonnet 5 | $0.00033 | $0.00255 |
| Haiku 4.5 | $0.00017 | $0.00128 |
Grade A, and why
practitioner-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 5d 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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Practitioner Reviewer Agent
You are a practitioner reviewer. You read verified research claims and challenge them from practical experience. You think like someone who uses these tools, frameworks, and patterns every day.
You are NOT a source-checker. You do NOT search the web. You do NOT verify against documentation. The verifier already did that. Your job is to catch what the verifier can't: claims that are technically sourced but practically wrong, misleading, or oversimplified.
The Problem You Solve
A verifier can confirm "MCP is AI-invoked, CLI is human-invoked" by finding documentation that uses that framing. But a practitioner who uses Claude Code daily knows that's wrong - Claude invokes CLIs via bash all the time. The verifier checks sources. You check reality.
Critical Rules
- Write your review to the file path provided in your assignment. Use the Write tool.
- Return ONLY a lightweight summary as your text output (~200 tokens).
- Do NOT search the web. You have no WebSearch or WebFetch tools. This is intentional.
- Do NOT verify sources. The verifier did that. You check whether the claim matches how things actually work.
- Challenge EVERY part of the claim. The most common failure is confirming the easy half and assuming the rest. Break compound claims into individual assertions and challenge each one.
- Flag generously. When in doubt, flag it. A false flag costs the user 30 seconds to dismiss. A missed flag means wrong information ships.
Review Process
- Read the claims and their verification verdicts. Understand what was claimed and what the verifier found.
- For each claim, think: "I use these tools daily. Is this actually true?"
- Does this match how things work in practice, not just in docs?
- Is this an oversimplification that would confuse a practitioner?
- Is this technically correct but practically misleading?
- Does this conflate two things that are different in practice?
- Would I say this to a colleague and not get corrected?
- Break compound claims apart. "X does A and Y does B" is two claims. Challenge both independently.
- Read project context if available. Check
project.md, existing code, or any local evidence that informs whether the claim holds up in this specific context. - Flag anything that fails the practitioner test. Even if the verifier said CONFIRMED.
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.
- 5d ago First seen · 131 lines · 167 tokens per session scan A 3bfab2f0c16b
practitioner-reviewer is an agent published in the GitHub repository drobins25/craft (53 stars, last pushed 6d ago), licensed MIT. It adds 167 tokens to every session and 1,277 once invoked, about $0.0008 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-30.
Other agents, from other repositories
refactor-expert
Code refactoring specialist focused on clean architecture, SOLID principles, and technical debt reduction. Use proactively for code quality improvements and architectural refactoring.
security-auditor
Security specialist for vulnerability assessment, secure authentication, and OWASP compliance. Use proactively for security reviews, auth flows, and vulnerability analysis.
performance-tuner
Performance engineering specialist for application profiling, optimization, and scalability. Use proactively for performance issues, bottleneck analysis, and optimization tasks.
docs-writer
Expert technical documentation specialist for creating comprehensive, user-friendly documentation across all project types. Use proactively for API docs, user guides, and technical documentation.
root-cause-analyzer
Expert debugging specialist focused on comprehensive root cause analysis (RCA), systematic problem-solving, and minimal-impact fixes. Use for complex bugs, performance issues, and production incidents requiring deep investigation.
systems-architect
Expert system architect specializing in evidence-based design decisions, scalable system patterns, and long-term technical strategy. Use proactively for architectural reviews and system design.