| name | golang-review |
| description | Evidence-backed Go review for bounds, APIs, concurrency, errors, security, tests, rollout, and controllers. Use when reviewing a Go diff, PR, or branch, or as the golang hat /review adds when the diff touches *.go, go.mod, or backend protos. |
Golang Review
One review axis: does this Go diff follow the evidence-backed conventions in
RULES.md? Each catalog rule carries an anonymous aggregate support count,
so findings cite the rule id and explain repository-visible impact rather than relying
on reviewer taste.
Runs standalone on any Go diff, or as the golang hat inside the /review panel
(one subagent, this skill as its contract).
Non-goals
- Anything
golangci-lint already enforces in the target repo -- read its config first and skip those.
- Generic Go style (gofmt, naming, comment grammar) with no RULES.md backing.
- Frontend, generated files (
*.pb.go, *_pb.go, *.connect.go, @generated/DO NOT EDIT), vendored code.
- Re-litigating the catalog: a rule you disagree with is feedback for the catalog, not a finding to invert.
Procedure
- Scope: diff from fixed point to HEAD, Go and proto files only. Note the repo's
.golangci.yml enabled linters; anything they enforce is out of scope.
- Classify the diff into domains: proto/API surface, service handlers, Temporal
workflows/activities, Kubernetes controllers, tests, config/rollout, tenant-facing
security paths, concurrency/lifecycle.
- Load the matching sections of RULES.md and the matching
/golang
domain files (PROTO-API, CONCURRENCY, ERRORS, TESTING, TEMPORAL, SECURITY, ROLLOUT,
STRUCTURE, CONTROLLERS). Apply every S/A rule in scope; B on clear violation; C/D
only when the diff plainly violates the statement.
- Check the tensions list in RULES.md and
/golang SKILL.md before writing a
finding -- positive-boolean vs fail-closed, enum-subset switches, keepalive,
filter objects vs strings are context-dependent, not violations.
- Report findings, each with: rule id, file:line, what the diff does, the required
change, and priority. Max 400 words as a panel hat; standalone runs may go longer
but stay catalog-backed.
Severity
- P0: fail-open security predicate, tenant egress bypassing safedial, plaintext
secret stored/returned/logged, progress committed before durable processing,
unversioned change breaking live Temporal histories.
- P1: any other S/A violation -- unbounded tenant-controlled growth, raw internal
errors on the public surface, missing staged removal, integration claim on mocks.
- P2: B violations; S/A cases needing a judgment call the author should answer.
- P3: C/D wording and polish.
Confirmed bugs stay P0/P1 regardless of fix size.
Output
Standard hat contract: findings must be diff-introduced, user-impacting, actionable,
each PR-comment-ready (What, Why tied to the catalog rule, Suggested fix, One-shot prompt).
When no rule in scope is violated: APPROVED -- <domains checked>, no catalog violations.
