Go Code Review
Review Go diffs against Go Wiki and Uber style rules with gofmt, go vet, and Must Fix / Should Fix / Nits output.
Overview
Go Code Review is an agent skill for the Ship phase that reviews Go changes against Go Wiki and Uber style standards with gofmt, go vet, and severity-grouped findings.
Install
npx skills add https://github.com/cxuu/golang-skills --skill go-code-reviewWhat is this skill?
- Ordered procedure: gofmt -d and go vet first, then file-by-file diff review
- Severity grouping via assets/review-template.md: Must Fix, Should Fix, Nits
- Rules sourced from Go Wiki CodeReviewComments and Uber Go Style Guide
- Explicit re-read validation step to drop ungrounded findings
- Delegates deep lint topics to companion go-linting skill where noted
- Findings grouped into Must Fix, Should Fix, and Nits severity buckets
Adoption & trust: 929 installs on skills.sh; 110 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to merge Go code and need a consistent community-style review without missing mechanical issues or vague nit comments.
Who is it for?
Indie Go maintainers reviewing their own diffs or small-team PRs who want wiki- and Uber-aligned checklists in a fixed template.
Skip if: Non-Go languages, greenfield architecture debates, or security-only audits without style and API surface review.
When should I use this skill?
When reviewing Go code or before submitting a Go PR; also proactively on any Go code changes per skill description.
What do I get? / Deliverables
You get a structured review with verified line references grouped as Must Fix, Should Fix, and Nits after mechanical gofmt and go vet passes.
- Structured review using review-template.md
- Severity-grouped findings with line references
- Summary of must-fix blockers
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship review because the skill is invoked on diffs and PRs, though the same checklist applies during Build backend work. Review subphase captures pre-merge quality gates solo Go maintainers run before opening or merging a pull request.
Where it fits
Run the checklist on a feature branch diff before opening a PR to catch comment-sentence and error-handling violations.
Self-review a new HTTP handler package against documentation and naming rules before pushing.
How it compares
Use as a Go community style reviewer, not as a substitute for golangci-lint configuration or language-agnostic security scanners.
Common Questions / FAQ
Who is go-code-review for?
Go developers and solo maintainers who want PR reviews aligned with Go Wiki CodeReviewComments and the Uber Go style guide.
When should I use go-code-review?
Use it in Ship before opening or merging a Go PR, and in Build when reviewing backend package changes—even proactively when the user did not ask for style review.
Is go-code-review safe to install?
It may run bash helpers for gofmt and go vet locally; review the Security Audits panel on this Prism page and scope allowed-tools before use in CI or shared repos.
SKILL.md
READMESKILL.md - Go Code Review
# Go Code Review Checklist ## Review Procedure > Use `assets/review-template.md` when formatting the output of a code review to ensure consistent structure with Must Fix / Should Fix / Nits severity grouping. 1. Run `gofmt -d .` and `go vet ./...` to catch mechanical issues first 2. Read the diff file-by-file; for each file, check the categories below in order 3. Flag issues with specific line references and the rule name 4. After reviewing all files, re-read flagged items to verify they're genuine issues 5. Summarize findings grouped by severity (must-fix, should-fix, nit) > **Validation**: After completing the review, re-read the diff once more to verify every flagged issue is real. Remove any finding you cannot justify with a specific line reference. --- ## Formatting - [ ] **gofmt**: Code is formatted with `gofmt` or `goimports` → [go-linting](../go-linting/SKILL.md) --- ## Documentation - [ ] **Comment sentences**: Comments are full sentences starting with the name being described, ending with a period → [go-documentation](../go-documentation/SKILL.md) - [ ] **Doc comments**: All exported names have doc comments; non-trivial unexported declarations too → [go-documentation](../go-documentation/SKILL.md) - [ ] **Package comments**: Package comment appears adjacent to package clause with no blank line → [go-documentation](../go-documentation/SKILL.md) - [ ] **Named result parameters**: Only used when they clarify meaning (e.g., multiple same-type returns), not just to enable naked returns → [go-documentation](../go-documentation/SKILL.md) --- ## Error Handling - [ ] **Handle errors**: No discarded errors with `_`; handle, return, or (exceptionally) panic → [go-error-handling](../go-error-handling/SKILL.md) - [ ] **Error strings**: Lowercase, no punctuation (unless starting with proper noun/acronym) → [go-error-handling](../go-error-handling/SKILL.md) - [ ] **In-band errors**: No magic values (-1, "", nil); use multiple returns with error or ok bool → [go-error-handling](../go-error-handling/SKILL.md) - [ ] **Indent error flow**: Handle errors first and return; keep normal path at minimal indentation → [go-error-handling](../go-error-handling/SKILL.md) --- ## Naming - [ ] **MixedCaps**: Use `MixedCaps` or `mixedCaps`, never underscores; unexported is `maxLength` not `MAX_LENGTH` → [go-naming](../go-naming/SKILL.md) - [ ] **Initialisms**: Keep consistent case: `URL`/`url`, `ID`/`id`, `HTTP`/`http` (e.g., `ServeHTTP`, `xmlHTTPRequest`) → [go-naming](../go-naming/SKILL.md) - [ ] **Variable names**: Short names for limited scope (`i`, `r`, `c`); longer names for wider scope → [go-naming](../go-naming/SKILL.md) - [ ] **Receiver names**: One or two letter abbreviation of type (`c` for `Client`); no `this`, `self`, `me`; consistent across methods → [go-naming](../go-naming/SKILL.md) - [ ] **Package names**: No stuttering (use `chubby.File` not `chubby.ChubbyFile`); avoid `util`, `common`, `misc` → [go-packages](../go-packages/SKILL.md) - [ ] **Avoid built-in names**: Don't shadow `error`, `string`, `len`, `cap`, `append`, `copy`, `new`, `make` → [go-declarations](../go-declarations/SKILL.md) --- ## Concurrency - [ ] **Goroutine lifetimes**: Clear when/whether goroutines exit; document if not obvious → [go-concurrency](../go-concurrency/SKILL.md) - [ ] **Synchronous functions**: Prefer sync over async; let callers add concurrency if needed → [go-concurrency](../go-concurrency/SKILL.md) - [ ] **Con