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 skills add existential-birds/beagle --skill go-code-reviewgit clone --depth 1 https://github.com/existential-birds/beagleWrote 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/skills/existential-birds/beagle/go-code-review)<a href="https://agentmods.dev/skills/existential-birds/beagle/go-code-review"><img src="https://agentmods.dev/badge/skills/existential-birds/beagle/go-code-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/skills/existential-birds/beagle/go-code-review"><img src="https://agentmods.dev/badge/skills/existential-birds/beagle/go-code-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.00074 | $0.01802 |
| Opus 5.5 | $0.00030 | $0.00721 |
| Sonnet 5.5 | $0.00015 | $0.00360 |
| Haiku 4.5 | $0.00007 | $0.00180 |
Grade A, and why
go-code-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 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 — 155 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Go Code Review
Review Workflow
Follow this sequence in order. Do not emit findings until every Pass below is satisfied.
-
Baseline
go.mod— Opengo.modand read thegodirective.
Pass: You can state the exactgo X.YYvalue (in the review preamble or working notes). Apply version-gated advice only when it matches this baseline (loop capture pre-1.22,slog/structured logging from 1.21,errors.Joinfrom 1.20). -
Read surrounding code — For each changed
.gofile, read full functions or logical units that contain the edits, not only the diff hunk.
Pass: At least one full enclosing function (or package-levelinit/var block) containing the change was read per changed file. -
Scope the checklist — Decide which Review Checklist blocks apply (error handling, concurrency, interfaces/types, resources, naming). Load references for those blocks; skip blocks that are irrelevant to the diff.
Pass: The review (or working notes) lists which checklist blocks you applied, or marks blocks N/A with a one-line reason tied to the diff (e.g. “no concurrency in change”). -
Pre-report verification — Load and follow review-verification-protocol.
Pass: The protocol’s Pre-Report Verification Checklist is satisfied for each finding you will report (actual code read, surrounding context checked, “wrong” vs “different style” distinguished, etc.).
Hard gates (same sequence, shorter)
| Step | Objective pass condition |
|---|---|
| 1 | go X.YY from go.mod is recorded before version-specific advice. |
| 2 | Full enclosing context read per changed file, not diff-only. |
| 3 | In-scope checklist blocks listed or N/A with diff-tied reason; references opened as needed. |
| 4 | review-verification-protocol completed for every reported issue. |
Output Format
Report findings as:
[FILE:LINE] ISSUE_TITLE
Severity: Critical | Major | Minor | Informational
Description of the issue and why it matters.
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 155 lines · 74 tokens per session scan A 3e54eb36ccb6
go-code-review is a skill published in the GitHub repository existential-birds/beagle (82 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 74 tokens to every session and 1,802 once invoked, about $0.0003 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-16.
Other skills, from other repositories
no-bare-casts
Writing as in TypeScript or TSX production code, modifying a file that contains a bare as cast, silencing a type error with a cast, encountering as unknown as, or reviewing a cast site.
splitting-oversized-modules
Split an oversized Python module (a thousand-plus-line logic.py, models.py, api.py, or its test file) into a package of one module per concern, mechanically and provably without changing behavior. Use on a request to split / break up / decompose a god module or move functions out of one, once a human has agreed to…
splitting-oversized-modules
Split an oversized Python module (a thousand-plus-line logic.py, models.py, api.py, or its test file) into a package of one module per concern, mechanically and provably without changing behavior. Use on a request to split / break up / decompose a god module or move functions out of one, once a human has agreed to…
r-tidyverse-style
Use when the user asks to review or clean up R code for tidyverse style, standardize formatting or names, remove redundant comments or wrappers, or make a behavior-preserving style pass. Also use when writing substantial new R package code if the user requests tidyverse style or the package already follows it. Not for…
solid-principles
SOLID principles checklist with Java examples. Use when a class has too many responsibilities, an abstraction leaks, or a dependency points the wrong way, and when the user asks about Single Responsibility, Open/Closed, Liskov, Interface Segregation or Dependency Inversion. For naming, duplication and method length…
ring:auditing-dependency-security
Auditing a dependency for supply-chain risk before install (pip/npm/go/cargo): checks typosquatting, maintainer/age risk, vulnerability DBs (OSV, GHSA, Socket), and lockfile hash pinning, then emits a risk score and approve/conditional/escalate/block decision. Use when adding or updating a dependency, reviewing a…