| name | golang-comments |
| description | Use this skill when writing or editing Go doc comments. Covers doc comment style, doc links ([pkg.Name] syntax), headings, lists, code blocks, and common formatting mistakes.
|
Go Doc Comments
Go doc comments appear immediately before top-level package, const,
func, type, and var declarations with no intervening blank lines.
Every exported (capitalised) name must have a doc comment.
Reference: go.dev/doc/comment
Doc Links — Most Important Rule
Use [Name] doc links to refer to Go symbols, not backtick code fences.
Doc link forms:
| Reference | Syntax |
|---|
| Same-package symbol | [Buffer], [Buffer.Reset] |
| Pointer type | [*Buffer] |
| Other package (short name) | [fmt.Errorf], [io.Reader] |
| Other package (full path) | [encoding/json.Decoder] |
| Package itself | [encoding/json], [path/filepath] |
Use a full import path only when the short name is ambiguous.
Doc links must be surrounded by punctuation, spaces, tabs,
or start/end of line — they do not trigger inside map[K]V or generics.
Use backticks only for:
- Inline shell commands or non-Go literals (
`go test ./...`)
- Values that are not Go identifiers (
`nil`, `true`)
- Parameter names referred to by their literal text
Comment Style by Declaration Kind
Package
Begin with "Package name …" as the first sentence.
For large packages, give a brief API overview with doc links.
package path
Only one source file in a multi-file package should have a package comment.
Type
Explain what each instance represents or provides.
Document zero-value semantics and concurrency guarantees.
type Buffer struct { ... }
type Regexp struct { ... }
Func / Method
Say what the function returns (or does, for side-effect functions).
Use "reports whether" for boolean-returning functions.
Name parameters directly in prose — no special syntax needed.
func Quote(s string) string
func HasPrefix(s, prefix string) bool
func Copy(dst Writer, src Reader) (n int64, err error)
Do not explain internal implementation details in doc comments;
keep those in body comments.
Const / Var
A single doc comment can introduce a group; individual members use
end-of-line comments.
var (
ErrInvalid = errInvalid()
ErrPermission = errPermission()
ErrNotExist = errNotExist()
)
Syntax Rules
Paragraphs
Unindented, non-blank lines form a paragraph.
Blank lines separate paragraphs.
Use semantic line breaks (one sentence or clause per source line).
Headings
A line starting with # (hash + space) is a heading,
provided it is unindented and surrounded by blank lines.
Only available in Go 1.19+.
Headings must be a single line; multi-line # prefixes are not headings.
Links
Define link targets at the end of the comment as [Text]: URL.
Use them inline as [Text].
package json
Plain URLs in prose are auto-linked in HTML renderings.
Lists
Indent list items with spaces/tabs.
Use -, *, +, or • for bullet items;
a decimal followed by . or ) for numbered items.
Nested lists are not supported — flatten them.
Code Blocks
Any indented (non-list) span is a code block rendered in fixed-width font.
Always separate code blocks from surrounding prose with a blank // line.
func Search(n int, f func(int) bool) int
Notes and Deprecations
package rc4
Common Mistakes
Accidental code blocks
Any indented line becomes a code block, even if unintentional.
Numbered lists not indented look like paragraphs + code blocks:
Wrapped continuation lines
A wrapped continuation that is not indented enough breaks out of
the list or code block:
Directives
//go:generate, //nolint:, and similar tool directives are not
part of the doc comment.
Gofmt moves them after a blank line at the end of the comment.
type Op uint8