go-development

# Go development Use current Go language and standard library facilities for new code. Follow an explicit project requirement to support an older Go version. Read every reference whose condition matches the work before making the decision it governs: - For module requirements, tool dependencies, or inspection of dependency source, read [Modules and dependencies](references/modules-and-dependencies.md). - For imports, names, declaration order, or file organization, read [Source organization](references/source-organization.md). - For process termination, structured logging, or errors, read [Errors and diagnostics](references/errors-and-diagnostics.md). - For interfaces, interface compliance, or concrete result types, read [Interfaces](references/interfaces.md). - When considering a callback API, accepting a function parameter, or passing a function or closure to a helper, read [Callbacks](references/callbacks.md). - For function shapes, resource acquisition and cleanup, construction, dependencies, or exported members, read [Signatures and construction](references/signatures-and-construction.md). - For map-shaped APIs or boolean API parameters, read [Map and boolean APIs](references/map-and-boolean-apis.md). - For parsing domain values, enums, copying and sharing semantics, receiver choice, or whether APIs and collections carry pointers or values, read [Type semantics](references/type-semantics.md). - For maps, slices, iterators, streaming, strings, or bytes, read [Collections and iteration](references/collections-and-iteration.md). - For context propagation, goroutines, channels, or synchronization, read [Context and concurrency](references/context-and-concurrency.md). - For JSON representation or encoding, read [JSON](references/json.md). - For UUIDs, identifiers, or random tokens, read [Identifiers and randomness](references/identifiers-and-randomness.md). - For filesystem access across a trust boundary, read [Filesystem](references/filesystem.md). - For HTTP routing, read [HTTP](references/http.md). - For Go tests or executable API examples, read [Testing](references/testing.md). - For property-based tests, test input generators, or fuzz targets, read [Property-based tests and fuzzing](references/property-based-testing.md). - For testing code that invokes external programs through `os/exec`, read [Subprocess tests](references/subprocess-tests.md). - For asynchronous behavior, event delivery, background workers, timers, or deadlines in tests, read [Async tests](references/async-tests.md). - For HTTP tests, read [HTTP tests](references/http-tests.md). - For benchmarks, read [Benchmarks](references/benchmarks.md). - For choosing or writing table tests, read [Table tests](references/table-tests.md). Combine these language-specific rules with the general skills that govern the decision: - `code-design` owns domain contracts, ownership, dependencies, and representation decisions. - `code-readability` owns the maintainer's mental model; Go guidance supplies language-specific naming and organization constraints. - `code-testing` owns the evidence a change needs and the behavior each test protects; Go guidance supplies Go test mechanics and conventions. - `code-comments` owns documentation judgment; Go guidance supplies Go-specific comment mechanics when present.