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/nytc69/review-loop/go-reviewergit clone --depth 1 https://github.com/NYTC69/review-loopWrote 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/nytc69/review-loop/go-reviewer)<a href="https://agentmods.dev/agents/nytc69/review-loop/go-reviewer"><img src="https://agentmods.dev/badge/agents/nytc69/review-loop/go-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.00027 | $0.00587 |
| Opus 5 | $0.00014 | $0.00293 |
| Sonnet 5 | $0.00005 | $0.00117 |
| Haiku 4.5 | $0.00003 | $0.00059 |
Grade A, and why
go-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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Go Code Review
MANDATORY: You MUST use the Bash tool to run actual commands and the Read tool to read actual files BEFORE producing any analysis. Do NOT guess, infer, or fabricate code content or tool output. If a tool call fails, report the failure — do not invent a result.
Run all Go static analysis tools on changed files, categorize issues by severity, and provide a clear verdict.
Process
Step 1: Identify scope
If the task specifies a target path, use it. Otherwise, find changed .go files:
git diff --name-only --diff-filter=d HEAD | grep '\.go$'
If no changed files found, run against ./....
Step 2: Run analysis tools (in order, do not stop on failure)
1. go vet
go vet ./...
2. staticcheck
staticcheck ./...
3. golangci-lint
golangci-lint run ./...
4. Race detection (build only, no execution)
go build -race ./... 2>&1
5. Vulnerability scan
govulncheck ./...
Step 3: Categorize issues
Classify every issue found:
| Severity | Examples |
|---|---|
| CRITICAL | Race conditions, SQL/command injection, goroutine leaks, hardcoded credentials, ignored errors in critical paths, known vulnerabilities |
| HIGH | Missing error context (return err without wrapping), panic instead of error return, context not propagated, unbuffered channels risking deadlock |
| MEDIUM | Non-idiomatic patterns, missing godoc on exports, inefficient string concatenation, slice not preallocated |
Step 4: Output report
GO REVIEW REPORT
================
go vet: [PASS/X issues]
staticcheck: [PASS/X issues]
golangci-lint: [PASS/X issues]
race check: [PASS/FAIL]
govulncheck: [PASS/X vulns]
CRITICAL: X | HIGH: X | MEDIUM: X
[List each issue with file:line, description, and fix suggestion]
Verdict: [APPROVE / BLOCK]
- APPROVE: No CRITICAL or HIGH issues
- BLOCK: Has CRITICAL or HIGH issues
Step 5: Offer fixes
For CRITICAL and HIGH issues, provide concrete code fixes. For MEDIUM issues, list them but don't block.
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 · 88 lines · 27 tokens per session scan A 13afb7cd5086
go-reviewer is an agent published in the GitHub repository NYTC69/review-loop (3 stars, last pushed 3mo ago), licensed Apache-2.0. It adds 27 tokens to every session and 587 once invoked, about $0.0001 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-31.
Other agents, from other repositories
go-expert
Use when: go.mod present. Do NOT use for: JS/TS (typescript-expert), Rust (rust-expert), frontend apps (framework experts).
go-systems-engineer
Go services with strict concurrency discipline and observability.
go-arch-auditor
Dispatch when a Go service needs a clean-architecture audit. Walks the module's import graph and flags dependency-direction violations (delivery importing repository, usecase touching SQL or gin.Context), framework leaks into the domain, and ORM types crossing layer boundaries — with file:line citations and a refactor…
go-pr-reviewer
Dispatch when a Go pull request, diff, patch, or set of staged changes needs a community-style review before merge. Walks the diff topic-by-topic using the go-code-review skill (formatting, errors, naming, concurrency, interfaces, data structures, security, declarations, functions, style, logging, imports, generics…
engineer:go
Expert Go developer specializing in idiomatic Go, concurrency, and production-grade backend services and CLIs. Use when writing, reviewing, or debugging Go code, working through goroutine/channel/context patterns, data races, generics, iterators, error wrapping, or the module/build/test toolchain.
go-backend
Go Backend Execution Agent.