AgentSkillsCN

go-professional

基于《Effective Go》《Go 代码审查意见》和 Google Go 风格指南的全面 Go 编码风格、代码审查与最佳实践指南。当您编写、审查或重构 Go 代码时，可选用此方案，以确保代码在命名、错误处理、接口设计、并发控制、测试以及程序结构等方面均遵循专业级规范。

SKILL.md
--- frontmatter
name: go-professional
description: Comprehensive Go style, code review, and best practices guide based on Effective Go, Go Code Review Comments, and Google Go Style Guide. This skill should be used when writing, reviewing, or refactoring Go code to ensure it follows professional-grade conventions for naming, error handling, interfaces, concurrency, testing, and program structure.

Go Professional

Overview

This skill integrates three authoritative Go style references into a single comprehensive resource:

  • •Effective Go — The official guide by the Go team covering idiomatic Go patterns, conventions, and language mechanics.
  • •Go Code Review Comments — Community-maintained supplement to Effective Go, collecting common code review feedback and style issues.
  • •Google Go Style Guide — Google's internal Go style guide covering style principles, decisions, and best practices for large-scale Go codebases.

These sources complement each other: Effective Go teaches the language idioms, Code Review Comments addresses frequent real-world mistakes, and the Google Style Guide provides comprehensive rules for professional teams.

When to use

  • •Writing new Go code (packages, types, functions)
  • •Reviewing or refactoring existing Go code
  • •Resolving naming, formatting, or structural questions
  • •Designing error handling, interfaces, or concurrency patterns
  • •Establishing team coding standards or review checklists
  • •Onboarding developers to Go best practices

Reference guide

Load the relevant file(s) from references/ based on the task.

Note: The ja/ subdirectories contain Japanese translations for human reference. Always load the English originals for processing.

Effective Go (references/01-effective-go/)

FileTopicWhen to consult
01-introduction.mdIntroduction and examplesGeneral orientation
02-formatting.mdgofmt, indentation, line lengthFormatting questions
03-commentary.mdComments and doc commentsWriting documentation
04-names.mdPackage names, getters, interfaces, MixedCapsNaming decisions
05-semicolons.mdSemicolon insertion rulesSyntax questions
06-control-structures.mdif, for, switch, type switchControl flow patterns
07-functions.mdMultiple returns, named results, deferFunction design
08-data.mdnew vs make, slices, maps, printing, appendData structure usage
09-initialization.mdConstants, iota, variables, init functionsInitialization patterns
10-methods.mdPointer vs value receiversMethod design
11-interfaces-and-other-types.mdInterfaces, conversions, type assertionsInterface design
12-blank-identifier.mdBlank identifier, unused importsBlank identifier idioms
13-embedding.mdInterface and struct embeddingComposition patterns
14-concurrency.mdGoroutines, channels, parallelizationConcurrent programming
15-errors.mdError types, panic, recoverError handling

Supplementary references (references/)

FileSourceWhen to consult
02-code-review-comments.mdGo WikiCode reviews, common style issues, naming, error handling
03-google-style-guide.mdGoogleStyle principles, readability, consistency guidelines
04-google-style-decisions.mdGoogleSpecific style decisions: naming, formatting, patterns
05-google-best-practices.mdGooglePractical guidance: testing, error handling, concurrency

Quick reference

Essential rules across all three sources:

  • •Formatting: Run gofmt. Do not fight the formatter.
  • •Naming: Short, concise names. MixedCaps not underscores. No Get prefix on getters. Package name avoids stutter (bufio.Reader not bufio.BufReader). Use ctx for context.Context, err for errors.
  • •Control flow: Eliminate unnecessary else after return. Keep the happy path unindented. Use switch over if-else chains.
  • •Error handling: Return errors as the last return value. Wrap with context (fmt.Errorf("op: %w", err)). Handle errors immediately; do not ignore them. Prefer error over panic.
  • •Error strings: Lower-case, no punctuation — they may be composed with other messages.
  • •Interfaces: Accept interfaces, return concrete types. One-method interfaces get -er suffix. Define interfaces at the consumer, not the implementer. Use compile-time checks (var _ Interface = (*Type)(nil)).
  • •Concurrency: Share memory by communicating. Use channels for synchronization. Prefer fixed worker pools. Do not start goroutines without knowing how they stop.
  • •Package design: Avoid package util. Do not export unnecessarily. Separate packages by responsibility, not by type.
  • •Testing: Use table-driven tests. Test behavior, not implementation. Use t.Helper() in test helpers.
  • •Comments: Every exported name needs a doc comment. Start with the name of the thing being described.
  • •Imports: Group into standard library, third-party, and local packages. Do not use dot imports except in tests.