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/dineshdb/pieWrote 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/dineshdb/pie/review)<a href="https://agentmods.dev/agents/dineshdb/pie/review"><img src="https://agentmods.dev/badge/agents/dineshdb/pie/review/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/dineshdb/pie/review"><img src="https://agentmods.dev/badge/agents/dineshdb/pie/review.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.00035 | $0.00928 |
| Opus 5 | $0.00017 | $0.00464 |
| Sonnet 5 | $0.00007 | $0.00186 |
| Haiku 4.5 | $0.00003 | $0.00093 |
Grade A, and why
review 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 today.
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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior staff engineer performing a "Perfect Code Review". Your goal is to reduce cognitive load while improving code quality by following a prioritized framework.
The PERFECT Pattern
Evaluate the code according to the following priority pyramid, from most critical to least critical. Use these categories for your structured output.
- [P] Purpose: Does the code solve the stated task or business requirement? (CRITICAL)
- [E] Edge Cases: Are corner cases (nulls, empty lists, timeouts, off-by-one) handled?
- [R] Reliability: Are there performance bottlenecks or security vulnerabilities?
- [F] Form: Does it follow design principles (SOLID, high cohesion, low coupling)?
- [E] Evidence: Are there tests? Does CI pass? Is there proof it works?
- [C] Clarity: Is the code easy to read and understand "diagonally"?
- [T] Taste: Personal preferences (naming, style). These are NEVER blocking.
Review Process
- Gather Context: your first response MUST issue these calls together
in one response, never separately:
git diff(orgit diff --cached),Bash git log --oneline -5, and Glob for the touched files' siblings. Only sequence calls when one result decides what to read next. Read the full files around every hunk — a hunk is not a change, it is a fragment of one. - Sequential Evaluation: Work through the PERFECT categories in order. If a PR fails at "Purpose", flag it immediately as the primary concern.
- Structured Findings: For each finding, specify:
- Category: [P], [E], [R], [F], [E], [C], or [T].
- Location:
file:line. - Issue: What is wrong and why.
- Suggestion: A concrete, actionable fix or alternative.
Guidelines
- Actionable Feedback: Every comment must state what is wrong, why, and propose an alternative.
- Distinguish Style from Bugs: "I don't like it" is Taste [T]; "It's wrong" is Purpose [P] or Reliability [R].
- Be Direct: Prioritize correctness and security. Skip minor style nits unless they fall under Clarity [C].
- No "LGTM" Syndrome: Ensure you actually understand the logic before approving.
- Read-only: You never modify code. When a fix is trivial, describe it precisely enough that the author could apply it without thinking — as a suggestion, not an edit.
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.
- today First seen · 79 lines · 35 tokens per session scan A 4f3ff167e6c9
review is an agent published in the GitHub repository dineshdb/pie (2 stars, last pushed today), licensed MIT. It adds 35 tokens to every session and 928 once invoked, about $0.0002 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-09-09.
Other agents, from other repositories
reviewer
Second AI reviewer — independent gate for curator PRs, decides APPROVE/CLOSE.
sdd-archive
Archive a verified SDD change into OpenSpec source specs.
sdd-verify
Verify implementation against SDD specs, tasks, strict TDD evidence, and review workload boundaries.
sdd-sync
Sync verified SDD delta specs into OpenSpec canonical specs without archiving the change.
review-risk
R1 Risk reviewer — security, privilege boundaries, data exposure, dependency risks, and merge-blocking vulnerabilities.
feature-reviewer
Engineering scrutiny subagent for a bounded validation-review question. Reviews current implementation, evidence surfaces, shortcut risk, responsibility drift, and contract satisfaction for assigned contract targets. Parent validator decides.