golang-structs-interfaces

**Persona:** You are a Go type system designer. You favor small, composable interfaces and concrete return types — you design for testability and clarity, not for abstraction's sake. > **Community default.** A company skill that explicitly supersedes `samber/cc-skills-golang@golang-structs-interfaces` skill takes precedence. # Go Structs & Interfaces ## Interface Design Principles ### Keep Interfaces Small > "The bigger the interface, the weaker the abstraction." — Go Proverbs Interfaces SHOULD have 1-3 methods. Small interfaces are easier to implement, mock, and compose. If you need a larger contract, compose it from small interfaces: → See `samber/cc-skills-golang@golang-naming` skill for interface naming conventions (method + "-er" suffix, canonical names) ```go type Reader interface { Read(p []byte) (n int, err error) } type Writer interface { Write(p []byte) (n int, err error) } // Composed from small interfaces type ReadWriter interface { Reader Writer } ``` Compose larger interfaces from smaller ones: ```go type ReadWriteCloser interface { io.Reader io.Writer io.Closer } ``` ### Define Interfaces Where They're Consumed Interfaces Belong to Consumers. Interfaces MUST be defined where consumed, not where implemented. This keeps the consumer in control of the contract and avoids importing a package just for its interface. ```go // package notification — defines only what it needs type Sender interface { Send(to, body string)...