Provides a rigorous workflow for Go development focusing on test-driven design and architectural clarity.
Install
mkdir -p .claude/skills/go-rig && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/9507" && unzip -o skill.zip -d .claude/skills/go-rig && rm skill.zipInstalls to .claude/skills/go-rig
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use this skill when building, reviewing, or refactoring Go code in this repository. It adds process discipline for TDD/ATDD, package boundaries, dependency injection, and review quality, and complements the always-on rules in AGENTS.md.Key capabilities
- →Implement TDD/ATDD workflow
- →Enforce package boundaries
- →Apply dependency injection
- →Review Go code quality
How it works
It enforces a test-first design discipline, explicit dependency injection, and domain-focused package boundaries for Go development.
Inputs & outputs
When to use go-rig
- →Refactor existing Go packages
- →Add new features using TDD
- →Review code for dependency injection consistency
About this skill
Go Rig
This is the native Codex Go workflow skill for this repository.
AGENTS.md owns:
- always-on project constraints
- Go version and toolchain expectations
- compatibility, dependency, testing, and command policy
This skill owns:
- TDD/ATDD workflow
- design and abstraction discipline
- dependency injection discipline
- package-boundary judgment
- review checklist for Go changes
When To Use
Use this skill when:
- implementing a new behavior
- refactoring Go code
- changing package boundaries
- changing exported APIs or JSON behavior
- adding test seams, DI, or acceptance coverage
Workflow
- Define the boundary behavior first.
- Add the smallest failing test at the closest useful layer.
- Implement the minimum code to pass.
- Refactor back to clarity.
- Repeat in small increments.
If tests are not being run in the current turn, still design the change test-first.
Testing Expectations
Each meaningful change should consider:
- happy path
- invalid input and validation failure
- edge and boundary cases
- error paths
- concurrency behavior when relevant
Use acceptance-style tests for user-visible behavior and unit tests for domain rules.
Design Discipline
- Start with concrete types.
- Add interfaces only when a real consumer needs substitution.
- Keep packages domain-focused.
- Avoid speculative abstractions.
- Inject collaborators at boundaries instead of constructing them deep in domain code.
- Prefer option structs over long positional parameter lists.
Package And API Discipline
- Keep exported APIs stable unless compatibility work is intentional.
- Keep root facade wrappers as zero-logic forwarding.
- Translate weakly typed edge data into strict domain types quickly.
- Avoid transport or persistence concerns leaking into core domain behavior.
Review Checklist
- Boundaries are coherent.
- Dependencies are explicit.
- Functions are readable in one pass.
- Tests cover behavior, not just implementation details.
- JSON and API compatibility changes were reviewed intentionally.
- Nil vs empty behavior is intentional.
- Concurrency changes have shutdown and ownership semantics.
Repository Notes
- The repository uses a root facade package over
internal/app<domain>/. - New functionality belongs in
internal/first, with root wrappers added only for compatibility. - This repo has a zero-dependency bias; do not assume external helper libraries for tests or comparisons.
When not to use it
- →When the project is not written in Go
- →When the user wants to bypass testing requirements
Prerequisites
Limitations
- →Requires adherence to strict design discipline
How it compares
It mandates a strict TDD/ATDD process and explicit dependency management, unlike standard Go development workflows.
Compared to similar skills
go-rig side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| go-rig (this skill) | 0 | 4mo | No flags | Intermediate |
| effective-go | 323 | 9mo | No flags | Beginner |
| go-dev-guidelines | 14 | 9mo | No flags | Intermediate |
| code-formatting | 1 | 2mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
effective-go
openshift
Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.
go-dev-guidelines
jumppad-labs
This skill should be used when writing, refactoring, or testing Go code. It provides idiomatic Go development patterns, TDD-based workflows, project structure conventions, and testing best practices using testify/require and mockery. Activate this skill when creating new Go features, services, packages, tests, or when setting up new Go projects.
code-formatting
openshift
MANDATORY: When writing Go tests, you MUST use 'When...it should...' format for ALL test names. When writing any Go code, you MUST remind user to run 'make lint-fix' and 'make verify'. These are non-negotiable HyperShift requirements.
tidb-test-guidelines
pingcap
Decide where to place TiDB tests and how to write them (basic structure, naming, testdata usage). Use when asked about test locations, writing conventions, shard_count limits, casetest categorization, or when reviewing test changes in code review.
lsp-hover-testing
MadAppGang
Automated LSP hover validation for Dingo transpiler. Use when testing hover functionality, validating position mappings, checking for hover drift, or debugging LSP issues after sourcemap changes.
code-coverage
viknesh20-20
Analyzes test coverage, identifies untested code paths, and generates tests for the most critical uncovered areas. Use to improve test coverage before releases.