SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsreview-go

review-go

Coding & development

View repository

Updated 10-16 06:50

About this skill

Skill: Review Go

Purpose

Only review code in Go to understand language and runtime conventions. Do not define scope (diff vs codebase) or perform security/architecture analysis; these are handled by scope and cognitive skills. Emit in standard formatfindings listfor aggregation. Focus on concurrency and goroutine lifecycle, context usage, error handling, resource management, API stability, type and zero-value semantics, and testability.

Core Objective

Primary objective: Produce a Go language/runtime findings list covering concurrency, context usage, error handling, resource management, API stability, type semantics, and testability for the given code scope.

Success criteria(all requirements must be met):

  1. ✅ Go-only scope: Only review Go language and runtime conventions; no scope selection, security, or architecture analysis performed
  2. ✅ Cover all seven Go dimensions: Evaluate concurrency/goroutine lifecycle, context usage, error handling, resource management, API stability, type/zero-value semantics, and testability where relevant
  3. ✅ Conform to findings format: Each finding includes location, category (语言-go), severity, title, description, and optional recommendation
  4. ✅ File:line references: All findings reference specific file locations with line numbers
  5. ✅ Exclude non-Go code: Do not analyze Go-specific rules for non-Go files unless explicitly in scope

Acceptance test: Does the output contain a Go-centric findings list with file:line references covering all relevant language/runtime dimensions without performing security, architecture, or scope analysis?

Scope boundaries (scope boundaries)

This skill is responsible for：

  • Goroutine lifecycle and leak prevention (channel closing, cancellation, WaitGroup)
  • Context propagation through request paths
  • Error handling (wrapping with %w、errors.Is/As , avoiding panics for expected errors)
  • Resource management (defer Close(), resp.Body.Close(), context cancel())
  • API stability and Go modules (exported types, backward compatibility, go.mod)
  • Type and zero-value semantics (nil interface vs typed nil, pointer/value receivers, slice/map initialization)
  • Testability (small interfaces, global injection, deterministic test seams)

This skill is not responsible for：

  • Scope selection - scope is provided by the caller
  • Security analysis - use "review-security"
  • Architecture analysis - use "review-architecture"
  • SQL-specific analysis - use review-sql
  • Full orchestrated review - use "review code"

Handoff point: When all Go findings are published, hand them off to orchestrate-code-review for aggregation. For SQL or security issues, note them and recommend the appropriate cognitive skill.

Use cases (use cases)

  • Orchestrated review: When orchestrate-code-review runs a Go project's scope -> language -> framework -> library -> cognitive, use as the language step.
  • Go-only review: when the user only wants to check language/runtime conventions (for example, after adding new Go files).
  • Pre-PR Go checklist: ensure concurrency, context, and error handling patterns are correct.

When to use: when the code being reviewed is Go and the task includes language/runtime quality. Scope (diff vs paths) is determined by the caller or user.

Behavior

Scope of this skill

  • Analyze：the given code scope(files or diff provided by the caller) for Go language and runtime conventions. Does not decide scope; accepts the code scope as input.
  • Do not: perform scope selection (diff vs codebase), security review, or architecture review; do not inspect Go-specific rules in non-Go files unless explicitly in scope.

Review checklist (Go dimensions only)

  1. Concurrency and goroutine lifecycle: correct use of goroutines, channels, synchronization primitives, WaitGroup usage, channel closing, select patterns, and avoiding goroutine leaks or data races.
  2. Context usage: context is passed through the request path, cancellation and deadlines are honored, context.Background() is avoided in request handlers, and context is not stored in long-lived structures.
  3. Error handling: check and return errors; wrap with %w ; use errors.Is/As; avoid panicking for expected errors; avoid error shadowing.
  4. Resource management：defer Close() for io.Closer,resp.Body.Close() for HTTP responses,Stop() for timers/Tickers,cancel() for contexts.
  5. API stability and modules: stability of exported APIs, changes to exported types and interfaces, backward compatibility, and Go version/module expectations (go.mod, build tags).
  6. Types and zero-value semantics: nil interface vs typed nil pitfalls, pointer vs value receivers, map/slice initialization, slice copying and aliasing, and zero-value correctness.
  7. Testability and interfaces: prefer small interfaces, injection over globals, and seams for deterministic testing.

Tone and references

  • Professional and technical: reference specific locations (file:line). Emit findings with location, category, severity, title, description, and recommendation.

Input & Output

Input

  • Code scope: the files or directories (or diff) already selected by the user or a scoping skill. This skill does not decide scope; it only checks the language conventions of the provided Go code.

Output

  • Emit zero or moreAppendix: Output contractin the format defined infindings。
  • The category of this skill islanguage。

Limits

Hard Boundaries

  • Do notperform security, architecture, or scope selection. Adhere to Go language and runtime conventions.
  • Do notgive conclusions without specific locations or actionable recommendations.
  • Do notCheck Go-specific rules for non-Go code unless the user explicitly includes it (e.g., embedded code snippets).

Skill Boundaries

Do not do these(other skills can handle them):

  • Do not select or define code scope - scope is determined by the caller or "review code"
  • Do not perform security analysis - use "review-security"
  • Do not perform architecture analysis - use "review-architecture"
  • Do not perform comprehensive SQL analysis — use review-sql

When to stop and hand off：

  • After all Go findings are published, hand them off to "orchestrate-code-review" for aggregation
  • When the user needs a comprehensive review (scope + language + cognitive), redirect to "review code"
  • When SQL or security issues are found, note them and suggest the appropriate cognitive skill

Self-Check

Core success criteria

  • Go-only scope: review only Go language and runtime conventions; no scope selection, security, or architecture analysis was performed
  • Covers all seven Go dimensions: where relevant, evaluate concurrency/goroutine lifecycle, context usage, error handling, resource management, API stability, type/zero-value semantics, and testability
  • Conforms to the findings format: each finding includes location, category (语言-go), severity, title, description, and optional recommendation
  • file:line references: all results reference specific file locations with line numbers
  • Excludes non-Go code: Go-specific rules for non-Go files are not analyzed unless explicitly in scope

Process quality checks

  • Were only Go language/runtime dimensions reviewed (no scope/security/architecture)?
  • Were the relevant concurrency, context usage, error handling, resource management, API stability, type semantics, and testability covered?
  • Does each finding include location, category=language, severity, title, description, and optional recommendation?
  • Does file:line reference the issue?

Acceptance tests

Does the output contain a Go-centric findings list with file:line references covering all relevant language/runtime dimensions, without performing security, architecture, or scope analysis?

Examples

Example 1: Goroutine leak

  • Input: A goroutine is started in a request handler that waits on a channel that is never closed or canceled.
  • Expected: Emit findings for goroutine leak and lost cancellation; reference the handler and channel usage. Category=language-go.

Example 2: Error handling

  • Input: A function returns fmt.Errorf("failed: %v", err) and the caller compares the error with == .
  • Expected: Emit a finding to wrap with %w and use errors.Is/As; reference the error construction and comparison. Category=language-go.

Example 3: Nil interface trap

  • Input: A function returns(*MyStruct)(nil)aserrorinterface; the caller checks "if err != nil".
  • Expected: Emitting a typed nil assigned to an interface is not a nil result; recommend returning an explicit "nil". Category=language-go.

Edge case: Go and SQL mixed

  • Input: A Go file with embedded SQL strings for database queries.
  • Expected: Review only Go conventions (context usage, error handling, resource cleanup). Do not emit SQL injection findings; that is for review-security or review-sql.