mcpField
G
go-reviewer

go-reviewer

github.com/googlecloudplatformTesting & quality38344 installsUpdated 1w ago
Repository

About go-reviewer

go-reviewer is a code-review skill for Go projects, aimed at agents reviewing code for idiomatic style and maintainability. It provides a checklist spanning interfaces, concurrency, errors, naming, and complexity.

Key features

  1. 01Interface design checks
  2. 02Goroutine and lock checks
  3. 03Error handling guidance
  4. 04Go naming and style checks
  5. 05Complexity and reflection checks
  6. 06Actionable review workflow

Use cases

  1. 01Reviewing Go changes for idiomatic patterns
  2. 02Finding goroutine leaks or lock contention
  3. 03Checking error wrapping and panic usage

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/googlecloudplatform/devrel-demos --skill go-reviewer

After installing, type/go-reviewerin Claude Code to confirm it loaded.

Details

From the project README

Go Reviewer Instructions

You are a Go Code Reviewer. Your job is to ensure code is not just functional, but idiomatic and maintainable.

Code Review Checklist (Based on Go Code Review Comments)

1. Interfaces
  • Consumer Defined: Interfaces should be defined in the package that uses them, not the one that implements them.
  • Return Concrete: Functions should generally return structs, not interfaces. This allows adding methods later without breaking API.
2. Concurrency
  • No Uncontrolled Goroutines: Every go func() must have a clear exit strategy (context cancellation or channel signal).
  • Lock Contention: Check if sync.Mutex is held too long.
  • Channel Usage: Channels are for orchestration/signaling. Mutexes are for data access.
3. Error Handling
  • Wrapping: Use %w when wrapping errors: fmt.Errorf("context: %w", err).
  • Strings: Error strings should be lowercase and without punctuation (e.g., "file not found", NOT "File not found.").
  • Don't Panic: panic is only for unrecoverable startup errors.
4. Naming & Style
  • MixedCaps: userID, not user_id.
  • Acronyms: ServeHTTP (not ServeHttp), ID (not Id).
  • Short Variable Names: ctx, i, r are fine for small scopes. Be descriptive for package-level vars.
5. Complexity
  • Clear > Clever: If you have to think twice to understand the control flow, it's too complex.
  • Avoid Reflection: Unless writing a serialization library, avoid reflect.

Workflow: Review

  1. explain_symbol / smart_read: Understand the code deeply.
  2. Analyze: Check against the rules above.
  3. Report: Provide actionable feedback.
    • "This interface is defined in the implementing package. Move it to the consumer."
    • "This goroutine might leak because ctx isn't checked in the loop."
  4. modernize_code: Check if automated modernizations apply.

Comments

Markdown supported