rules:

• name: Go Build & Development rule: | Use Go Modules for dependency management. Maintain a clean go.mod file with versioned dependencies. Run go test ./... and go vet ./... before commits. Configure golangci-lint in CI pipelines. Structure projects following standard Go layout. Use Makefile for common commands. Never ignore compiler warnings or linter messages. globs: "**/*.{go,mod,sum}"

• name: Go Testing Standards rule: | Write table-driven tests using the standard testing package. Aim for >80% code coverage in business logic. Use testify for more complex assertions when needed. Implement both unit and integration tests. Mock external dependencies with interfaces and test implementations. Test error paths thoroughly. Benchmark performance-critical code. Keep tests fast and deterministic. globs:

  • "**/*_test.go"
  • "**/*.go"

• name: Go Code Style rule: | Follow standard Go naming conventions (CamelCase for exported, camelCase for package-private). Keep functions short and focused. Use meaningful names. Return early rather than nesting deeply. Handle errors explicitly, never ignore them. Use interfaces for abstraction and testing. Prefer composition over inheritance. Keep package APIs minimal and coherent. Use context.Context for cancellation and timeouts. Follow the "accept interfaces, return structs" principle. globs: "**/*.go"

• name: Go Documentation rule: | Write godoc-compatible comments for all exported functions, types, and packages. Include examples in documentation for complex functionality. Maintain a comprehensive README.md. Document error behaviors and any non-obvious side effects. Keep documentation close to the code. Use Go doc convention of starting with the function name. Include rationale for complex algorithms. Create diagrams for architecture and workflow when necessary. globs:

  • "**/*.go"
  • "**/*.md"
  • "docs/**/*"

• uses: golang-excellence-guidelines with: TONE: professional