godoc-authoring

Structure and content rules for Go doc comments and inline comments. Use whenever the task involves a comment in Go source — writing a new one, editing or rewriting an existing one, reviewing or critiquing one, deciding whether a declaration needs one at all, or comparing two competing versions. Covers the four content slots and their order, why the first sentence names the thing it documents, the exception Kubernetes API types make to that rule, doc links versus bare names, what stands in for tags Go does not have, why a list of members should usually be the rule that defines them, how far a rewrite may grow, comments that a tool rather than a human reads (//go:, //nolint, +kubebuilder), and the extra rules for tests, package comments, and CRD field descriptions that ship to users. Applies to a one-line comment as much as to a twenty-line block. Language and wording are governed by english-developer-style, which this skill defers to and does not replace.