Claude Cursor Skill

writing-go

Idiomatic Go development. Use when writing Go code, designing APIs, reviewing

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download alexei-led-cc-thingz-src_skills_writing-go-ce56bb4.zip · 3 KB

alexei-led/cc-thingz 36 5 forks MIT Updated 1d ago

Part of alexei-led/cc-thingz — 91 skills

Install

skills CLI npx skills add https://github.com/alexei-led/cc-thingz/tree/master/src/skills/writing-go

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install alexei-led-cc-thingz@llmmart

Git git clone https://github.com/alexei-led/cc-thingz.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole alexei-led/cc-thingz collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Go Development

Check go.mod (go and toolchain lines) and CI before using version-gated APIs. Project conventions win over these defaults.

Defaults

Stdlib first: net/http, testing, flag, log/slog. Add a module only for a concrete requirement.
Concrete types in domain code. Consumers own small private interfaces; producers return concrete types.
Keep HTTP, CLI, database, and vendor SDK types out of domain packages. Map errors to status, exit code, or retry at the edge.
New binaries: cmd/<name> plus internal/. Use pkg/ only for code meant for external import.
Avoid package stutter: user.Store, not user.UserStore.
Doc comments on exported names start with the identifier and end with a period.
Every goroutine has an owner, a cancellation path, and a completion path. Use errgroup for errors or shared cancellation when the module already has it.

Version-Gated

1.24+: t.Context(), t.Chdir(), and b.Loop() in tests.
1.25+: sync.WaitGroup.Go when no error propagation is needed.
1.26+: stdlib crypto/hpke; new(expr) only when clearer than a local variable or composite literal; self-referential generic constraints belong in generic libraries, not business logic.
1.26+: testing/cryptotest.SetGlobalRandom swaps process-wide randomness, so never use it in parallel tests.
encoding/json/v2 is experimental and exists only under GOEXPERIMENT=jsonv2; use it only when the project already builds that way.

CLIs

Use the existing framework. Otherwise flag for single-command tools, Cobra for large command trees with completions, urfave/cli for small multi-command tools. Skip Viper unless already used.
Keep main thin: it calls run(ctx, args, stdin, stdout, stderr) error and maps the result to an exit code. Tests call run. Avoid log.Fatal; it skips deferred cleanup.
Config precedence: flag, env, config file, default.

References

testing.md: read when adding or reshaping tests, or when the test loop is slow.
linting.md: read when changing lint commands or golangci-lint config.

Done when the relevant build/test/lint checks pass on what you changed, or you name each check that did not run and why.

Files (cc-thingz)

.agentbundler

targets

claude.json 234 B

{
  "frontmatterPatch": {
    "agent": "engineer",
    "allowed-tools": [
      "Read",
      "Bash",
      "Grep",
      "Glob",
      "Edit",
      "Write",
      "LS"
    ],
    "context": "fork",
    "user-invocable": false
  }
}

references

linting.md 709 B

# Go Linting

Use the project lint command first. Edit loop, scoped to the changed package:

```bash
gofmt -w file.go
go vet ./pkg/name
golangci-lint run ./pkg/name
```

- Run the full configured golangci-lint set before finishing. `--fast-only` belongs only in an explicit hot-path command.
- Keep the golangci-lint cache; `golangci-lint cache clean` is not a routine fix.
- Let golangci-lint choose concurrency (it reads container CPU quota). Do not run two instances in one repo at once.
- Exclude generated, vendor, and fixture code in config, not with ad hoc command filters.
- Do not disable linters or loosen rules for speed. If one linter dominates runtime, propose a hot-path versus full-gate split.

testing.md 1.6 KB

# Go Testing

## Tools

- Stdlib `testing` by default. Keep testify, mockery, or other helpers only where the project already uses them.
- testify: `require` for prerequisites, `assert` for independent checks. Never call either from a spawned goroutine; `require` calls `FailNow`, which must run on the test goroutine.
- Table-driven tests with `t.Run` subtests for input and error matrices.
- Prefer hand-written fakes for private consumer interfaces over generated mocks.
- Mock matchers: match business-critical arguments exactly. Wildcard `context.Context` only when cancellation, deadline, and values are irrelevant. Use predicate matchers for partial structs, SQL, JSON, timestamps, or IDs.
- HTTP handlers: `httptest` at the request/response boundary.
- Put file fixtures under `testdata/`.

## Fast Loop

```bash
go test ./pkg/name
go test ./pkg/name -run 'TestCreate/duplicate'
go test -short ./...
```

- Use package-list mode (`go test ./pkg/name`). Bare `go test` runs in local-directory mode, which disables the result cache.
- Avoid `-count=1` unless you must bypass the cache for side effects or flake diagnosis.
- Gate slow external tiers with `testing.Short()`. Use integration build tags only if the project already splits tiers that way.
- Keep `-race`, coverage, and benchmarks off the hot path. Run `-race` when the change touches goroutines, shared state, timers, or channels.

## Concurrency and State

- Use `testing/synctest` (1.25+) or fake clocks and explicit synchronization. Never assert with sleeps.
- `t.Setenv` and `t.Chdir` panic in parallel tests; process-wide state and `t.Parallel` do not mix.

SKILL.md 2.6 KB

---
description: Idiomatic Go development. Use when writing Go code, designing APIs, reviewing
  Go implementations, or changing Go tests. Follow the module's target Go version.
  Prefer stdlib, concrete types, explicit errors, goroutine ownership, fast feedback,
  and behavior tests. NOT for Python, Rust, TypeScript, shell scripts, or infra-only
  work.
name: writing-go
---

# Go Development

Check `go.mod` (`go` and `toolchain` lines) and CI before using version-gated APIs. Project conventions win over these defaults.

## Defaults

- Stdlib first: `net/http`, `testing`, `flag`, `log/slog`. Add a module only for a concrete requirement.
- Concrete types in domain code. Consumers own small private interfaces; producers return concrete types.
- Keep HTTP, CLI, database, and vendor SDK types out of domain packages. Map errors to status, exit code, or retry at the edge.
- New binaries: `cmd/<name>` plus `internal/`. Use `pkg/` only for code meant for external import.
- Avoid package stutter: `user.Store`, not `user.UserStore`.
- Doc comments on exported names start with the identifier and end with a period.
- Every goroutine has an owner, a cancellation path, and a completion path. Use `errgroup` for errors or shared cancellation when the module already has it.

## Version-Gated

- 1.24+: `t.Context()`, `t.Chdir()`, and `b.Loop()` in tests.
- 1.25+: `sync.WaitGroup.Go` when no error propagation is needed.
- 1.26+: stdlib `crypto/hpke`; `new(expr)` only when clearer than a local variable or composite literal; self-referential generic constraints belong in generic libraries, not business logic.
- 1.26+: `testing/cryptotest.SetGlobalRandom` swaps process-wide randomness, so never use it in parallel tests.
- `encoding/json/v2` is experimental and exists only under `GOEXPERIMENT=jsonv2`; use it only when the project already builds that way.

## CLIs

- Use the existing framework. Otherwise `flag` for single-command tools, Cobra for large command trees with completions, urfave/cli for small multi-command tools. Skip Viper unless already used.
- Keep `main` thin: it calls `run(ctx, args, stdin, stdout, stderr) error` and maps the result to an exit code. Tests call `run`. Avoid `log.Fatal`; it skips deferred cleanup.
- Config precedence: flag, env, config file, default.

## References

- [testing.md](references/testing.md): read when adding or reshaping tests, or when the test loop is slow.
- [linting.md](references/linting.md): read when changing lint commands or golangci-lint config.

Done when the relevant build/test/lint checks pass on what you changed, or you name each check that did not run and why.