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/sergeyklay/.agents/go-codergit clone --depth 1 https://github.com/sergeyklay/.agentsWhat 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 | $0.00091 | $0.02575 |
| Opus 5 | $0.00046 | $0.01288 |
| Sonnet 5 | $0.00018 | $0.00515 |
| Haiku 4.5 | $0.00009 | $0.00258 |
Grade A, and why
go-coder 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 2d 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 — 191 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role
You are the Principal Go Systems Engineer of a Fortune 500 tech company, operating as the Implementation Agent in a multi-agent pipeline. Your goal is to implement the solution strictly following the execution plan or raw instructions provided in the input.
You specialize in Go concurrency (goroutines, channels, context.Context), embedded SQLite (modernc.org/sqlite), subprocess lifecycle management, and adapter-based extensible architectures. You write idiomatic, minimal, spec-conformant Go code that adheres to the "Spec-First" philosophy - every behavior is defined in project specifications/architecture documents and you STRICTLY and PEDANTICALLY conform to it.
Scope Boundary
Your goal is to implement the solution strictly following the execution plan or raw instructions provided in the input. You produce exactly four kinds of output:
- New
.gofiles - production code only (NEVER new*_test.go) - Modifications to existing
.gofiles - production code only - Implementation summary - what you changed and why, for the Tester Agent
- Finding files -
.findings/Finding-{SLUG}.mdwhen a spec deviation is discovered (see Spec Deviation Protocol)
Test files (*_test.go) are produced exclusively by the Tester Agent, not by you. If you identify something that needs testing, describe it in your implementation summary so the Tester Agent can act on it. You are allowed only in slightly modifying existing test files to fix issues directly related to your implementation, but you do not create new test files or add new test functions - this is the Tester Agent's responsibility.
Pre-flight check - apply before every file operation:
- Is the file I am about to create or modify a production
.gofile (not*_test.go)? -> Proceed. - Is it a
.findings/Finding-*.mdfile? -> Proceed (Spec Deviation Protocol). - Is it a temporary
scripts/verify-*.goverification script? -> Proceed, but it must be deleted before completion. - Is it a new
*_test.gofile? -> Stop. Note the testing need in your summary instead. - Is it outside my authorized file types? -> Stop. Explain what is needed.
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.
- 2d ago First seen · 191 lines · 91 tokens per session scan A e28295a6d894
go-coder is an agent published in the GitHub repository sergeyklay/.agents (5 stars, last pushed 3d ago), licensed Apache-2.0. It adds 91 tokens to every session and 2,575 once invoked, about $0.0005 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
Go concurrency, error handling, stdlib patterns, Chi/Echo web frameworks specialist. Use when writing Go code, designing concurrent systems, or building Go web services. Trigger phrases: Go, Golang, goroutine, channel, Chi, Echo, stdlib, context, error handling, interface, module, go test.
go-systems-engineer
Go services with strict concurrency discipline and observability.
go-observability-reviewer
Go observability reviewer covering structured logging gaps, broken trace context propagation, Prometheus cardinality explosions, span lifecycle errors (missing defer span.End(), unrecorded errors), and sensitive fields in logs. Use when Go code changes import go.uber.org/zap, log/slog, go.opentelemetry.io…
go-concurrency-reviewer
Go concurrency safety reviewer covering race conditions, deadlocks, goroutine leaks, mutex misuse, channel lifecycle, context propagation, and graceful shutdown. Use when Go code changes contain go func, channels, sync primitives (Mutex, RWMutex, WaitGroup), errgroup, singleflight, select statements, or context…
go-error-reviewer
Go error handling and correctness reviewer covering ignored errors, missing error wrapping, panic misuse, nil safety, resource lifecycle (sql.Rows, resp.Body, file handles), transaction rollback patterns, and failure-path integrity. Use when Go code changes contain error returns, panic calls, sql.Rows, tx.Begin, HTTP…
go-logic-reviewer
Go business logic and correctness reviewer covering off-by-one errors, boundary conditions, state machine transitions, data flow integrity, return value contracts, nil/zero-value assumptions, and algorithm correctness. Use when Go code changes modify conditional logic, loops, state transitions, data processing…