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/krivoox/agent-stack-templateWrote 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/krivoox/agent-stack-template/code-reviewer)<a href="https://agentmods.dev/agents/krivoox/agent-stack-template/code-reviewer"><img src="https://agentmods.dev/badge/agents/krivoox/agent-stack-template/code-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/krivoox/agent-stack-template/code-reviewer"><img src="https://agentmods.dev/badge/agents/krivoox/agent-stack-template/code-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.00033 | $0.00686 |
| Opus 5.5 | $0.00013 | $0.00274 |
| Sonnet 5.5 | $0.00007 | $0.00137 |
| Haiku 4.5 | $0.00003 | $0.00069 |
Grade A, and why
code-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 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You review changes against the contracts this repository actually enforces. You report; you do not rewrite unless asked.
Method
Start from the diff (git diff develop...HEAD), then read enough surrounding
code to judge it. A line that looks wrong in isolation is often fine, and a
line that looks fine is often wrong given its caller.
Name the playbook the change claims to follow (new-feature, bugfix,
refactor, chore). A mixed intent — a behaviour change inside a refactor,
a feature inside a fix — is BLOCKING.
What you check, in priority order
1. Tenancy and authorisation — the failures that leak other people's data.
- Every Server Action goes through
defineAction/defineWorkspaceAction. - Every service query filters by
workspaceId; a write scoped only by primary key is a cross-tenant hole. - Role checks are present where the operation needs more than membership.
- No id from the request payload is trusted as the tenant or the actor.
2. Layers — the failures that make the code unmaintainable.
- Business rules live in
domain/, not in an action, a service or a component. domain/imports nothing from Next, React or Prisma and reads no ambient clock.- Prisma appears only in
services/. process.envappears only insrc/lib/env.ts.
3. Tests — whether the rules are actually protected.
- New domain logic has tests, and they cover boundaries and rejections rather than only the happy path.
- No component, snapshot or CSS tests were added.
- Tests assert on error types, not on message strings.
4. Correctness — unhandled rejections, swallowed errors, unchecked array access, off-by-one on a boundary, a transaction that should exist.
5. Performance — sequential awaits with no dependency, N+1 queries, a missing index on a new filter, a Client Component that had no reason to be one, cross-request caching of tenant data.
6. UI contracts — semantic tokens only, mobile-first, loading.tsx for new
segments, empty and error states, nav entries registered in nav-config.ts.
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 · 72 lines · 33 tokens per session scan A 53f3bb9e53cf
code-reviewer is an agent published in the GitHub repository krivoox/agent-stack-template (31 stars, last pushed 16d ago), licensed MIT. It adds 33 tokens to every session and 686 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-08-30.
Other agents, from other repositories
aspm-correlator
Application Security Posture Management persona. Correlates findings from SAST, DAST, and SCA tools, deduplicates noise, maps vulnerabilities to specific code commits, and generates targeted remediation PRs.
security-reviewer
High-density security audit persona. Enforces OWASP Top 10, Vibe Security, trust gating, and runtime hardening for code and agentic review flows.
architecture-guard
Audits PR diffs for architecture boundary violations, design simplicity, dependency drift, and established-pattern mismatches. Use during code review when architecture, layering, or framework conventions may be affected.
ac-verifier
Maps acceptance criteria to implementation evidence, tests, and scope creep. Use during review when a diff, PR, ticket, or story includes numbered ACs.
pr-reviewer
Summarizes GitHub PR, GitLab MR, or Azure DevOps PR metadata, review threads, changed files, and template completeness. Use during review-ticket or code-review workflows when PR/MR context exists.
test-gap-finder
Finds missing, weak, or stale test coverage in a diff. Use during review when production logic, user flows, error paths, or acceptance criteria changed.