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 inference-gateway/adk --skill go-spec-reviewergit clone --depth 1 https://github.com/inference-gateway/adkWrote 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/inference-gateway/adk/go-spec-reviewer)<a href="https://agentmods.dev/skills/inference-gateway/adk/go-spec-reviewer"><img src="https://agentmods.dev/badge/skills/inference-gateway/adk/go-spec-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/skills/inference-gateway/adk/go-spec-reviewer"><img src="https://agentmods.dev/badge/skills/inference-gateway/adk/go-spec-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.00093 | $0.01162 |
| Opus 5 | $0.00046 | $0.00581 |
| Sonnet 5 | $0.00019 | $0.00232 |
| Haiku 4.5 | $0.00009 | $0.00116 |
Grade A, and why
go-spec-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 11d 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.
This is a copy
94% identical to go-spec-reviewer — 54 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 107 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Go Spec Reviewer
Dispatch a subagent to verify a Go design spec is complete, consistent, and idiomatic before implementation begins - the cheapest place to catch a flawed design. The reviewer channels Rob Pike, the stdlib authors, and spf13: reject needless abstraction, demand explicit error handling and context propagation, expect the simplest design that works. It complements plan mode with a focused spec gate.
When to use
- A spec or design doc to review, or the question "is this spec ready?"
- About to implement from a written spec
- A technical review of a planned feature before any code is written
How to dispatch
Spawn a general-purpose subagent (the Agent tool) pointed at the spec file,
with the prompt below. It returns Status / Issues / Recommendations - it does
not edit code.
You are a Go spec reviewer. Verify this spec is complete and ready for
implementation, through the lens of idiomatic Go.
Think like Rob Pike: is it simple, doing one thing well?
Think like the stdlib authors: small interfaces, defined at the point of use?
Spec to review: <SPEC_FILE_PATH>
Step 1 - Codebase context. Before reviewing, explore the repo for conventions and
conflicts: this is the A2A ADK, a Go library with two public surfaces - server/
(build an A2A agent, assembled via A2AServerBuilder / AgentBuilder) and client/
(call one) - plus types/ (A2A wire types, generated from schema.yaml - never
hand-edit) and server/config/ (envconfig-driven Config). Note the deliberate
interface seams the spec should reuse rather than reinvent: TaskHandler /
StreamableTaskHandler, LLMClient, Storage (in-memory vs Redis), and the artifact
storage interfaces. Mocks are counterfeiter-generated under client/mocks/ and
server/mocks/.
Step 2 - Go philosophy:
| Concern | Look for |
| ----------- | -------- |
| Simplicity | layers/abstractions with one implementation; over-engineering |
| Interfaces | consumer-defined? small (1-3 methods)? real polymorphism? |
| Errors | returned explicitly, wrapped with %w, never silently swallowed? |
| Context | ctx threaded through I/O and long calls? timeouts set? |
| Concurrency | goroutines with clear ownership and a stop condition? races? |
| Packages | one clear purpose each? new package justified vs extending one? |
| Naming | short, no stutter (pkg.PkgThing)? |
| YAGNI | driven by stated requirements, not speculative futures? |
Step 3 - A2A / ADK conventions:
| Concern | Look for |
| ------------- | -------- |
| Wire types | reuses types/ (generated); no ad-hoc structs duplicating A2A schema? |
| Handlers | new behaviour hangs off TaskHandler/StreamableTaskHandler or callbacks, not a parallel dispatch path? |
| Builders | new construction options added as WithXxx on the relevant builder? |
| Streaming | emits the documented CloudEvents (adk.agent.*); producer owns/closes the channel? |
| Storage | works against the Storage interface (in-memory and Redis), not one backend? |
| Schema | protocol changes deferred upstream to inference-gateway/schemas, not invented here? |
Step 4 - Completeness:
| Category | Look for |
| ------------ | -------- |
| Completeness | TODO/TBD/placeholders, missing error paths |
| Consistency | contradictions, types named differently across sections |
| Clarity | ambiguity that would make two implementors build different things |
| Scope | one focused implementation, not several subsystems |
| Security | user input sanitized before shell/path/external use? |
Calibration: only flag issues that would cause real implementation problems - a
missing error path, an interface that won't compose with the existing handler
seams, an abstraction that adds complexity without enabling anything. Skip wording
and formatting nits. Respect THIS repo's established conventions (the
server/client/types split, the fluent builders, counterfeiter-generated mocks,
pluggable storage and artifact backends, generated wire types); judge idiomaticity
within them - do not flag the chosen architecture itself as a defect. Approve
unless gaps would lead to a flawed or incomplete implementation.
Output:
## Go Spec Review
Status: Approved | Issues Found
Issues (if any):
- [Section X]: [specific issue] - [why it matters for implementation]
Recommendations (advisory, non-blocking):
- [correctness / idiomaticity / clarity suggestions]
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.
- 11d ago First seen · 107 lines · 93 tokens per session scan A 2bc0cc0db2cf
go-spec-reviewer is a skill published in the GitHub repository inference-gateway/adk (25 stars, last pushed yesterday), licensed Apache-2.0. It adds 93 tokens to every session and 1,162 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. It is 94% identical to go-spec-reviewer, differing in 54 lines, and is treated as a copy.
Other skills, from other repositories
python-math
Small Python utilities for math and text files.
go-proverbs
Validate Go code changes against Go Proverbs.
go-code-review
Use when reviewing Go code or checking code against community style standards. Also use proactively before submitting a Go PR or when reviewing any Go code changes, even if the user doesn't explicitly request a style review. Does not cover language-specific syntax — delegates to specialized skills.
github
GitHub operations via gh CLI: issues, PRs, CI runs, code review, API queries. Use when: (1) checking PR status or CI, (2) creating/commenting on issues, (3) listing/filtering PRs or issues, (4) viewing run logs. NOT for: complex web UI interactions requiring manual browser flows (use browser tooling when available)…
cmd_go_review
Comprehensive Go code review for idiomatic patterns, concurrency safety, error handling, and security. Invokes the go-reviewer agent.
ax-go-gen
Use when writing Go code with github.com/ax-llm/ax/packages/go for AxGen programs, forward calls, indexed multi-sampling, result pickers, streaming, tools, assertions, traces, usage, and output parsing.