agent-ready-go
Skill19 starsChanged 8 months agoMITView on GitHub
Prepares Go applications to work effectively with AI coding agents. Use when setting up a new Go project or retrofitting an existing one to ensure: structured JSON logging (slog/Zap/ZeroLog/Logrus), machine-readable command output, thorough golangci-lint configuration, non-interactive CLI design with --yes flags, structured error handling with meaningful exit codes, proper context.Context propagation, graceful shutdown, health check endpoints, and a standardized Makefile. Triggers when a user asks to make their Go app "agent-ready," "AI-friendly," wants to improve agent tooling/observability in a Go project, or needs to audit an existing Go project against agent-readiness best practices.
In this repository53 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .claude/skills/agent-rules/AGENTS.mdAGENTS.md
- .github/workflows/AGENTS.mdAGENTS.md
- pkg/AGENTS.mdAGENTS.md
- agent-rulesSkill
- architecture-designerSkill
- cli-developerSkill
- cloudformation-to-pulumiSkill
- code-reviewerSkill
- commitlintSkill
- commitSkill
- csharp-developerSkill
- decideSkill
- dep-upgradeSkill
- design-principlesSkill
- devops-engineerSkill
- flux-cliSkill
- flux-operator-cliSkill
- golang-proSkill
- go-nolint-auditSkill
- javascript-proSkill
- kubernetes-specialistSkill
- lint-fixSkill
- markdownlintSkill
- prSkill
- pull-request-msg-with-ghSkill
- pulumi-arm-to-pulumiSkill
- pulumi-automation-apiSkill
- pulumi-best-practicesSkill
- pulumi-cdk-to-pulumiSkill
- pulumi-cliSkill
- pulumi-componentSkill
- pulumi-escSkill
- pulumi-goSkill
- pulumi-neoSkill
- pulumi-pythonSkill
- pulumi-terraform-to-pulumiSkill
- pulumi-typescriptSkill
- python-proSkill
- reviewSkill
- roadmapSkill
- rust-async-patternsSkill
- rust-best-practicesSkill
- rust-engineerSkill
- scoutSkill
- security-auditSkill
- spring-boot-engineerSkill
- sre-engineerSkill
- sync-websiteSkill
- tailscale-installSkill
- tech-debtSkill
- the-foolSkill
- typescript-proSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 1 is distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 42
Run this checklist against the project.
- Very specific: line 69
Use JSON format when !isatty(os.Stdout.Fd()) or LOG_FORMAT=json
- Very specific: line 71
Never use fmt.Println for operational log output
- Very specific: line 137
Never call os.Exit deep in business logic — return errors up
- Very specific: line 138
Never panic outside of init() / package-level setup
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- Copyright 2025-2026 Richard Shade. Licensed under Apache-2.0. --><!-- SPDX-License-Identifier: Apache-2.0 -->Agent-Ready Go
Make Go applications work effectively with AI coding agents by ensuring all tooling produces machine-readable output, errors are structured, and commands run non-interactively by default.
Workflow
Making a Go app agent-ready involves these steps:
- Audit — identify gaps against the agent-readiness checklist
- Structured logging — add/configure slog, Zap, ZeroLog, or Logrus with JSON output
- Machine-readable output — ensure all commands can emit JSON
- Linting — add
.golangci.ymlwith thorough config - Testing — ensure
go test -race -count=1 -timeout=5mwith coverage thresholds - Error handling — structured errors, meaningful exit codes
- Non-interactive design —
--yes/-yflags, env vars over prompts - Makefile — standardize
build,test,lint,covertargets
For greenfield projects, apply all steps. For existing projects, run the audit first and address only what's missing.
Step 1: Audit
Run this checklist against the project. Address each ❌:
- Structured logger configured (slog / Zap / ZeroLog / Logrus)
- Logger outputs JSON when not a TTY or when
LOG_FORMAT=json - CLI commands support
--jsonor--output jsonflag .golangci.ymlexists with a thorough linter setgo test -racepasses- Code coverage ≥ 80% enforced
go vet ./...passes clean- All errors wrapped with context (
fmt.Errorf("...: %w", err)) - Exit codes: 0 = success, non-zero = failure (no panics in CLI entry)
context.Contextthreaded through all I/O-bound functions- Interactive prompts have
--yes/-ybypass flag Makefilewithbuild,test,lint,cover,citargets- Graceful shutdown on SIGTERM/SIGINT (HTTP services)
- Health check endpoints (
/healthz,/readyz) for HTTP services govulncheck ./...passes cleanNO_COLORrespected; no ANSI codes in non-TTY output- Config loaded from env vars with validation at startup
Step 2: Structured Logging
See references/logging.md for setup patterns for slog, Zap, ZeroLog, and Logrus.
Key requirements:
- Use JSON format when
!isatty(os.Stdout.Fd())orLOG_FORMAT=json - Include fields:
level,ts,msg, plus context fields - Never use
fmt.Printlnfor operational log output - Log to stderr; keep stdout clean for machine-readable data
Step 3: Machine-Readable Output
Agents parse stdout to validate results. Every non-trivial command must support JSON output.
var outputJSON bool
cmd.Flags().BoolVar(&outputJSON, "json", false, "output results as JSON")
if outputJSON {
enc := json.NewEncoder(os.Stdout)
enc.SetIndent("", " ")
_ = enc.Encode(result)
} else {
fmt.Printf("Created: %s\n", result.Name)
}Rule: structured data → stdout; progress/human messages → stderr.
fmt.Fprintln(os.Stderr, "Processing...") // progress to stderr
json.NewEncoder(os.Stdout).Encode(result) // data to stdoutStep 4: Linting
Copy assets/.golangci.yml to the project root, then:
golangci-lint run ./...Requires golangci-lint v1.59+ (v1.x series).
See references/testing.md for linter explanations and tuning guidance.
Step 5: Testing
See references/testing.md for full testing setup.
go test -race -count=1 -timeout=5m -coverprofile=coverage.out ./...
go tool cover -func=coverage.out | tail -1Enforce minimum coverage in CI:
COVERAGE=$(go tool cover -func=coverage.out | tail -1 | awk '{print $3}' | tr -d '%')
[ $(echo "$COVERAGE >= 80" | bc -l) -eq 1 ] || { echo "Coverage ${COVERAGE}% < 80%"; exit 1; }Step 6: Error Handling
See references/error-handling.md for structured error patterns and exit code conventions.
Quick rules:
- Always wrap:
fmt.Errorf("loading config: %w", err) - CLI
main()catches all errors and exits with appropriate code - Never call
os.Exitdeep in business logic — return errors up - Never
panicoutside ofinit()/ package-level setup
Step 7: Non-Interactive Design
See references/non-interactive.md for patterns.
Any prompt that blocks agent execution must have a --yes/-y bypass:
if !yes {
confirmed, _ := promptConfirm("Delete all records?")
if !confirmed {
return nil
}
}
// proceedStep 8: Makefile
Copy assets/Makefile to the project root. Adjust
BINARY_NAME and MAIN_PKG for the project.
Standard targets: make build, make test, make lint, make cover,
make ci (runs full pipeline).
Resources
| File | Contents |
| references/logging.md | slog, Zap, ZeroLog, Logrus JSON setup |
| references/testing.md | Race detector, coverage, golangci-lint tuning |
| references/error-handling.md | Structured errors, exit codes, context |
| references/non-interactive.md | --yes flags, env vars, stdin detection |
| references/services.md | HTTP graceful shutdown, health checks, OTel, request ID |
| references/config.md | Configuration management, env var parsing, validation |
| assets/.golangci.yml | Production-ready linter config |
| assets/Makefile | Standard build/test/lint/cover targets |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

