SkillAtlasSkill 详情

golang-documentation

AI agent skills are reusable instruction sets that extend your coding assistant with domain-spec...

审核状态:已审核Quality 80Security 80

复制安装命令

用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。

复制前请先查看来源、License 和安全提示。

项目 README

来源文件:README.md

抓取于 2026年8月8日

Agent Skills for production-ready Golang projects

AI agent skills are reusable instruction sets that extend your coding assistant with domain-specific expertise, loaded on demand so they don't bloat your context. This repository covers Go-specific skills only (language, testing, security, observability, etc.); for dev workflow skills (git conventions, CI/CD, PR reviews) you'll want to add a separate skills plugin.

For generic skills, please visit cc-skills.

[!IMPORTANT] Bootstrapped with Claude Code by distilling my Go project commits. Edited, tested, reviewed and reworked by a human.

No AI slop here. AI-made skills are useless.

image

🚀 How to use

Install with skills CLI (universal, works with any Agent Skills-compatible tool):

npx skills add https://github.com/samber/cc-skills-golang --all
# or a single skill:
npx skills add https://github.com/samber/cc-skills-golang --skill golang-performance
Claude Code
/plugin marketplace add samber/cc
/plugin install cc-skills-golang@samber
Openclaw

Copy skills into the cross-client discovery directory:

git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/skills/cc-skills-golang
# or in workspace:
git clone https://github.com/samber/cc-skills-golang.git ~/.openclaw/workspace/skills/cc-skills-golang
Gemini CLI
gemini extensions install https://github.com/samber/cc-skills-golang

Update with gemini extensions update cc-skills-golang.

Cursor

Copy skills into the cross-client discovery directory:

git clone https://github.com/samber/cc-skills-golang.git  ~/.cursor/skills/cc-skills-golang

Cursor auto-discovers skills from .agents/skills/ and .cursor/skills/.

Copilot

Copy skills into the cross-client discovery directory:

/plugin install https://github.com/samber/cc-skills-golang
# or
git clone https://github.com/samber/cc-skills-golang.git ~/.copilot/skills/cc-skills-golang

Copilot auto-discovers skills from .copilot/skills/.

OpenCode

Copy skills into the cross-client discovery directory:

git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang

OpenCode auto-discovers skills from .agents/skills/, .opencode/skills/, and .claude/skills/.

Codex (OpenAI)

Clone into the cross-client discovery path:

git clone https://github.com/samber/cc-skills-golang.git ~/.agents/skills/cc-skills-golang

Codex auto-discovers skills from ~/.agents/skills/ and .agents/skills/. Update with cd ~/.agents/skills/cc-skills-golang && git pull.

Antigravity

Clone and symlink into the cross-client discovery path:

git clone https://github.com/samber/cc-skills-golang.git ~/.antigravity/skills/cc-skills-golang

Update with cd ~/.antigravity/skills/cc-skills-golang && git pull.

🧩 Skills

These skills are designed as atomic, cross-referencing units. A skill may reference conventions defined in another (e.g. error-handling rules that affect logging live in golang-error-handling, not golang-observability). Installing only a subset will give you a partial and potentially inconsistent view of the guidelines. For best results, install all general-purpose skills together.

                         ┌────────────────────────────────────────┐
                         │             Golang Skills              │
                         └──────────────────┬─────────────────────┘
                                            │
   ┌─────────────────┬──────────────────────┼──────────────────────┐
   ▼                 ▼                      ▼                      ▼
┌──────────────┐ ┌──────────────┐ ┌─────────────────┐ ┌──────────────────────┐
│ Code Quality │ │ Arch & Design│ │    QA & Perf    │ │    Project Start     │
├──────────────┤ ├──────────────┤ ├─────────────────┤ ├──────────────────────┤
│ code-style   │ │ design-patt  │ │ testing         │ │ project-layout       │
│ naming       │ │ concurrency  │ │ benchmark       │ │ popular-libs         │
│ error-handl  │ │ context      │ │ performance     │ │ cli                  │
│ safety       │ │ dep-inject   │ │ troubleshoot    │ │ continuous-integ.    │
│ structs-iface│ │ data-structs │ │ observability   │ │ stay-updated         │
│ documentation│ │ database     │ │                 │ │ dep-management       │
│ lint         │ │ modernize    │ │                 │ │ gopls                │
│ security     │ │ refactoring  │ │                 │ │ pkg-go-dev           │
└──────────────┘ └──────────────┘ └─────────────────┘ └──────────────────────┘

    ┌─────────────────────────────────────────────────────────────────────────┐
    │                      Framework / Library Skills                         │
    ├──────────────┬────────────────┬──────────────┬─────────────┬───────────┤
    │   APIs       │      DI        │  Frameworks  │  samber/*   │  Testing  │
    ├──────────────┼────────────────┼──────────────┼─────────────┼───────────┤
    │ grpc         │ google-wire    │ spf13-cobra  │ samber-lo   │ stretchr- │
    │ graphql      │ uber-dig       │ spf13-viper  │ samber-mo   │  testify  │
    │ swagger      │ uber-fx        │              │ samber-ro   │           │
    │              │                │              │ samber-do   │           │
    │              │                │              │ samber-hot  │           │
    │              │                │              │ samber-slog │           │
    │              │                │              │ samber-oops │           │
    └──────────────┴────────────────┴──────────────┴─────────────┴───────────┘

  • ⭐️ Recommended
  • ✅ Published
  • 👷 Work in progress
  • ❌ To-do
  • ⚡ Command available
  • 🧠 Ultrathink automatically
  • 🤖 Ultracode automatically
  • ⚙️ Overridable (see doc below)
  • Description (tok): weight of the description field from YAML frontmatter, always loaded into Claude's context for skill triggering
  • SKILL.md (tok): weight of the full SKILL.md file loaded when the skill triggers
  • Directory (tok): weight of all files in the skill directory (SKILL.md + referenced markdown files)

General purpose:

SkillFlagsError rate gapDescription (tok)SKILL.md (tok)Directory (tok)
⭐️✅ golang-code-style⚡ 🤖 ⚙️-40%1152,3412,957
⭐️✅ golang-data-structures⚡-39%932,5996,318
⭐️✅ golang-database⚡ ⚙️-38%972,7127,234
⭐️✅ golang-design-patterns⚡ ⚙️-37%802,6859,391
⭐️✅ golang-documentation⚡ 🤖 ⚙️-53%753,07811,177
⭐️✅ golang-error-handling⚡ 🤖 ⚙️-26%1411,7184,677
⭐️✅ golang-how-to⚡—1654,01713,853
⭐️✅ golang-modernize⚡ 🤖-61%682,9209,233
⭐️✅ golang-naming⚡ ⚙️-23%1593,0227,390
⭐️✅ golang-refactoring⚡ 🧠 🤖 ⚙️—2463,70820,216
⭐️✅ golang-safety⚡-58%782,6055,375
⭐️✅ golang-testing⚡ 🧠 🤖 ⚙️-32%1154,2347,341
⭐️✅ golang-troubleshooting⚡ 🧠 🤖-32%1282,89416,577
⭐️✅ golang-security⚡ 🧠 🤖-32%853,16021,596
✅ golang-benchmark⚡ 🧠-50%1023,04230,224
✅ golang-cli⚡-43%1252,3296,144
✅ golang-concurrency⚡ 🤖 ⚙️-39%722,1806,810
✅ golang-context⚡ ⚙️-34%821,2024,012
✅ golang-continuous-integration⚡-59%823,29112,553
✅ golang-dependency-injection⚡ 🤖 ⚙️-47%1782,9945,265
✅ golang-dependency-management⚡-54%772,3615,499
✅ golang-structs-interfaces⚡ ⚙️-35%1113,0673,067
✅ golang-lint⚡ 🤖-41%981,8536,181
✅ golang-observability⚡ 🤖 ⚙️-37%1643,09618,583
✅ golang-performance⚡ 🧠 🤖-39%1302,19018,190
✅ golang-gopls⚡—2192,30812,188
✅ golang-pkg-go-dev⚡—2303,4285,242
✅ golang-popular-libraries⚡-30%511,0444,438
✅ golang-project-layout⚡-38%691,5635,778
✅ golang-stay-updated⚡-56%441,8011,801

Tools:

SkillFlagsError rate gapDescription (tok)SKILL.md (tok)Directory (tok)
✅ golang-google-wire⚡-16%1222,6617,391
✅ golang-graphql-16%763,0617,932
✅ golang-grpc⚡-41%702,3325,148
✅ golang-spf13-cobra⚡—1762,5717,342
✅ golang-spf13-viper⚡—1702,5427,089
✅ golang-swagger⚡—1442,3333,338
✅ golang-uber-dig⚡-10%1072,5766,248
✅ golang-uber-fx⚡-5%1182,8167,051
✅ golang-samber-do⚡-81%711,8773,392
✅ golang-samber-hot⚡-54%1191,9777,407
✅ golang-samber-lo⚡-40%1672,60110,279
✅ golang-samber-mo⚡ 🧠-48%822,94311,358
✅ golang-samber-oops⚡-59%702,5352,847
✅ golang-samber-ro⚡ 🧠-50%1542,95211,168
✅ golang-samber-slog⚡-19%1193,1119,833
❌ golang-temporal—000
✅ golang-stretchr-testify⚡-47%921,8492,668

🧪 Skill evaluations

With SkillWithout SkillDelta
Overall3315/3395 (98%)1915/3395 (56%)+41pp

See EVALUATIONS.md for the full per-skill breakdown.

📖 Skills description

Code Quality

golang-code-style

Go code formatting and conventions. gofmt, goimports, linting rules, comment conventions, and project-level style consistency. Overridable by company skills.

golang-documentation

Go documentation standards. Package docs, godoc conventions, code comments, example functions, README structure, and API reference generation. Overridable.

golang-error-handling

Go error handling best practices. Error creation, wrapping with fmt.Errorf and errors.Is/As, sentinel errors, custom error types, error codes, and panic recovery. Overridable.

golang-lint

Go linting best practices and golangci-lint configuration. Presets, custom rules, CI integration, inline suppression, and output interpretation.

golang-naming

Go naming conventions across all identifier types. Packages, constructors, structs, interfaces, constants, errors, receivers, acronyms, test functions. Covers MixedCaps rules, Get-prefix, and utils/helpers anti-patterns. Overridable.

golang-safety

Defensive Go coding. Prevents panics, silent data corruption, and runtime bugs. nil safety, append aliasing, map concurrent access, float comparison, zero-value design, numeric overflow.

golang-security

Go security best practices. Injection prevention (SQL, command, XSS), cryptography, filesystem/network safety, secrets management, cookie security, and tool configuration. Audit and review modes.

golang-structs-interfaces

Go struct and interface design. Composition, embedding, type assertions, interface segregation, struct tags (JSON/YAML/DB), pointer vs value receivers. Overridable.

Architecture & Design

golang-concurrency

Go concurrency patterns. Goroutines, channels, sync primitives, context cancellation, worker pools, fan-out/fan-in, pipelines. Overridable.

golang-context

Idiomatic context.Context usage. Creation, cancellation, timeouts, values, propagation patterns, and common anti-patterns. Overridable.

golang-data-structures

Go data structures internals and usage. Slices (capacity growth, append aliasing), maps, channels, sync primitives, and when to use each.

golang-database

Go database access patterns. Parameter binding, connection pooling, transactions, migrations, sqlboiler/sqlc code generation, query builders. Overridable.

golang-dependency-injection

Dependency injection patterns in Go. Constructor injection, interface-based DI, wire/dig/fx comparison, and when DI is worth the complexity. Overridable.

golang-design-patterns

Idiomatic Go design patterns. Functional options, constructors, builder pattern, middleware chains, circuit breaker, and architecture guides with file trees and code. Overridable.

golang-modernize

Modernize Go code to use recent language features. Range-over-int, min/max builtins, iterators, slices/maps/cmp/slog stdlib packages, testing patterns (t.Context, b.Loop, synctest), and tooling upgrades.

golang-refactoring

Safe, at-scale refactoring process for existing Go code. Coverage-adaptive safety net, tool-driven behavior-preserving transforms (gopls Rename/Inline/Extract, gofmt -r, eg, gopatch), the Fowler catalog mapped to Go, breaking import cycles, type-alias gradual code repair, and a human-in-the-loop workflow of staged PRs on a refactoring branch.

QA & Performance

golang-benchmark

Go benchmarking, profiling, and performance measurement. pprof, trace, CPU/memory/block profiles, flame graphs, benchmark comparison (benchstat), continuous profiling.

golang-observability

Go production observability. Structured logging (slog), Prometheus metrics, OpenTelemetry tracing, pprof profiling, RUM tracking, alerting, Grafana dashboards. Overridable.

golang-performance

Go performance optimization. Allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, hot-path optimization. Review and hot-path modes.

golang-testing

Production-ready Go tests. Table-driven tests, fuzzing, fixtures, goroutine leak detection (goleak), snapshot testing, code coverage, integration tests, parallel tests. Overridable.

golang-troubleshooting

Systematic Go debugging methodology. Common pitfalls, test-driven debugging, pprof capture, Delve debugger, race detection, GODEBUG tracing, production debugging.

Project Setup

golang-cli

Go CLI application development. Project layout, exit codes, signal handling, I/O patterns, argument parsing, and terminal UX.

golang-continuous-integration

CI/CD pipeline configuration for Go projects using GitHub Actions. Build, test, lint, and release workflows.

golang-dependency-management

Go module dependency strategies. go.mod conventions, versioning, replace directives, tool dependencies, and multi-module workspaces.

golang-gopls

Semantic code intelligence for your local build via gopls, the official Go language server. Go-to-definition, find references, call/implementation hierarchy, workspace symbol search, diagnostics, safe rename, and refactors (extract/inline/fill/rewrite). Reachable via gopls's own MCP server, Claude Code's native LSP tool, or the gopls CLI.

golang-pkg-go-dev

Go package and module exploration via godig, a pkg.go.dev API client (CLI + MCP server). Package docs, API references, symbols, code examples, versions, importers, licenses, and known vulnerabilities. Prefer over Context7 for Go packages.

golang-popular-libraries

Curated recommendations for production-ready Go libraries and frameworks. When the stdlib is enough vs when to reach for a package.

golang-project-layout

Go project structure and workspace setup. cmd/internal/pkg conventions, monorepo layout, CLI project structure, and when to keep things flat.

golang-stay-updated

Resources to stay current with Go. Official channels, community hubs, key people to follow, and learning resources.

APIs

golang-graphql

GraphQL API development in Go using gqlgen/graphql-go. Schema definition, resolvers, subscriptions, dataloader, and federation.

golang-grpc

gRPC in Go. Protobuf organization, service definitions, streaming, interceptors, error codes, and code generation workflow.

golang-swagger

OpenAPI/Swagger docs with swaggo/swag. Annotation comments, code generation, framework integrations (gin, echo, fiber, chi), security definitions.

Dependency Injection

golang-google-wire

Compile-time dependency injection with google/wire. Provider sets, injector generation, wire.Build, and structured DI patterns.

golang-uber-dig

Reflection-based DI with uber-go/dig. Provide/Invoke, dig.In/dig.Out, named values, value groups, optional dependencies, and Decorate.

golang-uber-fx

Application framework with uber-go/fx. fx.New, fx.Provide/Invoke, fx.Module, lifecycle hooks, fx.Annotate, fx.Decorate, signal-aware Run.

Frameworks

golang-spf13-cobra

CLI command trees with spf13/cobra. Command hierarchy, RunE hooks, flag management, shell completion, usage templates, and testing with SetArgs.

golang-spf13-viper

Layered configuration with spf13/viper. Flag > env > file > KV > default precedence, BindPFlag, hot reload, test isolation, and remote KV integration.

samber/*

golang-samber-do

Dependency injection with samber/do. Type-safe service containers, lifecycle management, scopes, health checks, and graceful shutdown.

golang-samber-hot

In-memory caching with samber/hot. 9 eviction algorithms (LRU, LFU, TinyLFU, W-TinyLFU, S3FIFO, ARC, SIEVE...), TTL, loaders, sharding, stale-while-revalidate, Prometheus metrics.

golang-samber-lo

Functional programming helpers with samber/lo. 500+ type-safe generic functions for slices, maps, channels, strings. Immutable (lo), parallel (lop), mutable (lom), iterators (loi), SIMD.

golang-samber-mo

Monadic types with samber/mo. Option, Result, Either, Future, IO, Task, State for type-safe nullable values, error handling, and functional composition.

golang-samber-oops

Structured error handling with samber/oops. Error builders, stack traces, error codes, context attributes, public vs developer messages, panic recovery, and APM integration.

golang-samber-ro

Reactive streams with samber/ro. 150+ type-safe operators, cold/hot observables, 5 subject types, 40+ plugins, automatic backpressure, and Go context integration.

golang-samber-slog

Structured logging pipeline with samber/slog-**** packages. Multi-handler routing (slog-multi), sampling, formatting, HTTP middleware, and 20+ backend sinks.

Testing

golang-stretchr-testify

Testing with stretchr/testify. assert, require, mock, and suite packages. Assertions, mock expectations, argument matchers, suite lifecycle, and custom matchers.

🕵 Use in CI for AI-driven reviews

Add AI agents as PR reviewers alongside traditional static analysis. When configured with this skill plugin, the agent applies the relevant Go skills per review area — catching architectural drift, logic bugs, and concurrency hazards that linters cannot detect.

See GOLANG-AI-DRIVEN-REVIEW.md for full setup instructions (Claude Code Action and GitHub Copilot).

🎯 Tuning Skill Triggers

If a skill triggers too often or not often enough, please open an issue suggesting a description change. The description field in SKILL.md frontmatter is the primary triggering mechanism — small wording adjustments can significantly improve trigger accuracy. Some SKILL.md files might have a When to use section which is another level of exclusion. Finally, SKILL.md files are an entrypoint for lazy loading references with deep knowledge located in references/.

🔄 Overlap

Claude reports very little overlap between skills in this repo, thanks to cross-reference. I suggest enabling most of the skills and leveraging lazy loading. The recommended ⭐️ skills load ~1,100 tokens of descriptions at startup; full skill content is only pulled in when relevant. Note:

  • I estimate that 50% of golang-naming and golang-code-style overlap with linters (golangci-lint).
  • A large part of the security rules in golang-security have been distilled from the Bearer (SAST) checklist. The skill is still useful for methodology.
  • If your team has its own conventions, create a company skill and declare the override explicitly near the top of its body: This skill supersedes samber/cc-skills-golang@golang-naming skill for [company] projects. Skills marked ⚙️ in the table above support this mechanism.

✍️ Contribute

  • 100 tokens per skill description - what? when to use this skill?
  • 1.000–2.500 tokens per SKILL.md — keep the main file focused on essentials
  • Use secondary markdown files for depth — reference them from SKILL.md with relative links (e.g., [Logging](./logging.md)). Claude reads these on demand when the topic is relevant, so they don't count against the context budget until needed
  • Up to 10.000 tokens for full skill and secondary files
  • 2–4 skills loaded simultaneously in a typical session — design skills to coexist
  • Stay below ~10k tokens of total loaded SKILL.md anytime to avoid degrading response quality

For more guidelines, please check CLAUDE.md.

💫 Fuel the Revolution

  • ⭐️ Star this repo - Your star powers the caffeine engine!
  • ☕️ Buy me a coffee - I'll literally use it to build more skills while drinking actual coffee

GitHub Sponsors

📝 License

Copyright © 2026 Samuel Berthe.

This project is under MIT license.

开发与工程文档与办公内容与创作

中风险

  • 来源需自行核对维护者身份。
  • 包含脚本或命令调用,安装前请复核。
  • 未检测到明显外部权限要求。
  • 未检测到高风险命令。
  • 扫描发现:3 条。

Codex — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/samber/cc-skills-golang.git
  3. 将 "skills/golang-documentation" 文件夹复制到 Codex 的 skills 目录中。
  4. 重启 Codex 让新的 skill 生效。

Codex — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Codex 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Codex 让新的 skill 生效。

Claude Code — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/samber/cc-skills-golang.git
  3. 将 "skills/golang-documentation" 文件夹复制到 Claude Code 的 skills 目录中。
  4. 重启 Claude Code 让新的 skill 生效。

Claude Code — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Claude Code 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Claude Code 让新的 skill 生效。

Cursor — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/samber/cc-skills-golang.git
  3. 将 "skills/golang-documentation" 文件夹复制到 Cursor 的 skills 目录中。
  4. 重启 Cursor 让新的 skill 生效。

Cursor — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Cursor 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Cursor 让新的 skill 生效。

GitHub Copilot — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/samber/cc-skills-golang.git
  3. 将 "skills/golang-documentation" 文件夹复制到 GitHub Copilot 的 skills 目录中。
  4. 重启 GitHub Copilot 让新的 skill 生效。

GitHub Copilot — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 GitHub Copilot 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 GitHub Copilot 让新的 skill 生效。

Windsurf — Git Clone 安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 克隆仓库:git clone https://github.com/samber/cc-skills-golang.git
  3. 将 "skills/golang-documentation" 文件夹复制到 Windsurf 的 skills 目录中。
  4. 重启 Windsurf 让新的 skill 生效。

Windsurf — 手动复制安装

  1. 安装前请先查看来源仓库和风险报告。
  2. 从源仓库下载 SKILL.md 及相关文件。
  3. 在 Windsurf 的 skills 目录中创建新文件夹。
  4. 将所有 skill 文件复制到新文件夹中。
  5. 重启 Windsurf 让新的 skill 生效。
查看 SKILL.md 原文
name: golang-documentation
description: "Comprehensive documentation guide for Golang projects, covering godoc comments, README, CONTRIBUTING, CHANGELOG, Go Playground, Example tests, API docs, and llms.txt. Use when writing or reviewing doc comments, documentation, adding code examples, setting up doc sites, or discussing documentation best practices. Triggers for both libraries and applications/CLIs."
user-invocable: true
license: MIT
compatibility: Designed for Claude Code or similar AI coding agents, and for projects using Golang.
metadata:
  author: samber
  version: "1.1.6"
  openclaw:
    emoji: "📝"
    homepage: https://github.com/samber/cc-skills-golang
    requires:
      bins:
        - go
    install: []
allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch

Persona: You are a Go technical writer and API designer. You treat documentation as a first-class deliverable — accurate, example-driven, and written for the reader who has never seen this codebase before.

Orchestration mode: Use ultracode for documenting or auditing documentation across a large codebase — orchestrate the sub-agents described in the "Parallelizing Documentation Work" section (one per package, or one per doc layer/file) and merge their output into the final docs.

Modes:

  • Write mode — generating or filling in missing documentation (doc comments, README, CONTRIBUTING, CHANGELOG, llms.txt). Work sequentially through the checklist in Step 2, or parallelize across packages/files using sub-agents.
  • Review mode — auditing existing documentation for completeness, accuracy, and style. Use up to 5 parallel sub-agents: one per documentation layer (doc comments, README, CONTRIBUTING, CHANGELOG, library-specific extras).

Community default. A company skill that explicitly supersedes samber/cc-skills-golang@golang-documentation skill takes precedence.

Go Documentation

Write documentation that serves both humans and AI agents. Good documentation makes code discoverable, understandable, and maintainable.

Cross-References

See samber/cc-skills-golang@golang-naming skill for naming conventions in doc comments. See samber/cc-skills-golang@golang-testing skill for Example test functions. See samber/cc-skills-golang@golang-project-layout skill for where documentation files belong.

Writing Principles

Apply to every piece of documentation you write or review:

Concision — write the shortest version that carries the idea. Remove ornament and hollow transitions. Never drop facts, warnings, or user-requested depth.

Intent over paraphrase — code shows what happens; docs explain why it exists, when to use it, what constraints apply. A comment that only restates the signature wastes the reader's time.

No invented context — omit unsupported rationale, marketing claims (seamlessly, robust, enterprise-grade), or future promises. Leave gaps visible rather than filling with speculation.

Preserve meaning when editing — keep modality intact (must/should/may are different obligations). Preserve conditions, warnings, required actions. A cleaner sentence that changes obligations is wrong.

Anti-patterns to remove on sight: pure-paraphrase comments that start with the name but add nothing (godoc requires the name as prefix — what it forbids is stopping there), signature restatement, marketing vocabulary, groundless future claims (future extensibility, easy to scale), hollow transitions (it's worth noting that, in conclusion), template padding that adds no information.

Step 1: Detect Project Type

Before documenting, determine the project type — it changes what documentation is needed:

Library — no main package, meant to be imported by other projects:

  • Focus on godoc comments, ExampleXxx functions, playground demos, pkg.go.dev rendering
  • See Library Documentation

Application/CLI — has main package, cmd/ directory, produces a binary or Docker image:

Both apply: function comments, README, CONTRIBUTING, CHANGELOG.

Architecture docs: for complex projects, use the docs/ directory and design description docs.

Step 2: Documentation Checklist

Every Go project needs these (ordered by priority):

ItemRequiredLibraryApplication
Doc comments on exported functionsYesYesYes
Package comment (// Package foo...) — MUST existYesYesYes
README.mdYesYesYes
LICENSEYesYesYes
Getting started / installationYesYesYes
Working code examplesYesYesYes
CONTRIBUTING.mdRecommendedYesYes
CHANGELOG.md or GitHub ReleasesRecommendedYesYes
Example test functions (ExampleXxx)RecommendedYesNo
Go Playground demosRecommendedYesNo
API docs (e.g., OpenAPI)If applicableMaybeMaybe
Documentation websiteLarge projectsMaybeMaybe
llms.txtRecommendedYesYes

A private project might not need a documentation website, llms.txt, Go Playground demos...

Parallelizing Documentation Work

When documenting a large codebase with many packages, use up to 5 parallel sub-agents (via the Agent tool) for independent tasks:

  • Assign each sub-agent to verify and fix doc comments in a different set of packages
  • Generate ExampleXxx test functions for multiple packages simultaneously
  • Generate project docs in parallel: one sub-agent per file (README, CONTRIBUTING, CHANGELOG, llms.txt)

Step 3: Function & Method Doc Comments

Every exported function and method MUST have a doc comment. Document complex internal functions too. Skip test functions.

The comment starts with the function name and a verb phrase. Focus on why and when, not restating what the code already shows. The code tells you what happens — the comment should explain why it exists, when to use it, what constraints apply, and what can go wrong. Include parameters, return values, error cases, and a usage example:

// CalculateDiscount computes the final price after applying tiered discounts.
// Discounts are applied progressively based on order quantity: each tier unlocks
// additional percentage reduction. Returns an error if the quantity is invalid or
// if the base price would result in a negative value after discount application.
//
// Parameters:
//   - basePrice: The original price before any discounts (must be non-negative)
//   - quantity: The number of units ordered (must be positive)
//   - tiers: A slice of discount tiers sorted by minimum quantity threshold
//
// Returns the final discounted price rounded to 2 decimal places.
// Returns ErrInvalidPrice if basePrice is negative.
// Returns ErrInvalidQuantity if quantity is zero or negative.
//
// Play: https://go.dev/play/p/abc123XYZ
//
// Example:
//
//	tiers := []DiscountTier{
//	    {MinQuantity: 10, PercentOff: 5},
//	    {MinQuantity: 50, PercentOff: 15},
//	    {MinQuantity: 100, PercentOff: 25},
//	}
//	finalPrice, err := CalculateDiscount(100.00, 75, tiers)
//	if err != nil {
//	    log.Fatalf("Discount calculation failed: %v", err)
//	}
//	log.Printf("Ordered 75 units at $100 each: final price = $%.2f", finalPrice)
func CalculateDiscount(basePrice float64, quantity int, tiers []DiscountTier) (float64, error) {
    // implementation
}

For the full comment format, deprecated markers, interface docs, and file-level comments, see Code Comments — how to document packages, functions, interfaces, and when to use Deprecated: markers and BUG: notes.

Step 4: README Structure

README SHOULD follow this exact section order. Copy the template from templates/README.md:

  1. Title — project name as # heading
  2. Badges — shields.io pictograms (Go version, license, CI, coverage, Go Report Card...)
  3. Summary — 1-2 sentences explaining what the project does
  4. Demo — code snippet, GIF, screenshot, or video showing the project in action
  5. Getting Started — installation + minimal working example
  6. Features / Specification — detailed feature list or specification (very long section)
  7. Contributing — link to CONTRIBUTING.md or inline if very short
  8. Contributors — thank contributors (badge or list)
  9. License — license name + link

Common badges for Go projects:

[![Go Version](https://img.shields.io/github/go-mod/go-version/{owner}/{repo})](https://go.dev/) [![License](https://img.shields.io/github/license/{owner}/{repo})](./LICENSE) [![Build Status](https://img.shields.io/github/actions/workflow/status/{owner}/{repo}/test.yml?branch=main)](https://github.com/{owner}/{repo}/actions) [![Coverage](https://img.shields.io/codecov/c/github/{owner}/{repo})](https://codecov.io/gh/{owner}/{repo}) [![Go Report Card](https://goreportcard.com/badge/github.com/{owner}/{repo})](https://goreportcard.com/report/github.com/{owner}/{repo}) [![Go Reference](https://pkg.go.dev/badge/github.com/{owner}/{repo}.svg)](https://pkg.go.dev/github.com/{owner}/{repo})

For the full README guidance and application-specific sections, see Project Docs.

Step 5: CONTRIBUTING & Changelog

CONTRIBUTING.md — Help contributors get started in under 10 minutes. Include: prerequisites, clone, build, test, PR process. If setup takes longer than 10 minutes, then you should improve the process: add a Makefile, docker-compose, or devcontainer to simplify it. See Project Docs.

Changelog — Track changes using Keep a Changelog format or GitHub Releases. Copy the template from templates/CHANGELOG.md. Each entry answers what changed for the reader — internal refactors without user-visible impact belong in commit history. Don't inflate a fixed edge case into a broad "reliability improvement" claim. See Project Docs.

Step 6: Library-Specific Documentation

For Go libraries, add these on top of the basics:

  • Go Playground demos — create runnable demos and link them in doc comments with // Play: https://go.dev/play/p/xxx. Use the go-playground MCP tool when available to create and share playground URLs.
  • Example test functions — write func ExampleXxx() in _test.go files. These are executable documentation verified by go test.
  • Generous code examples — include multiple examples in doc comments showing common use cases.
  • godoc — your doc comments render on pkg.go.dev. Use go doc locally to preview; to inspect how a published package renders its docs, symbols, and examples, → See samber/cc-skills-golang@golang-pkg-go-dev skill.
  • Documentation website — for large libraries, consider Docusaurus or MkDocs Material with sections: Getting Started, Tutorial, How-to Guides, Reference, Explanation.
  • Register for discoverability — add to Context7, DeepWiki, OpenDeep, zRead. Even for private libraries.

See Library Documentation for details.

Step 7: Application-Specific Documentation

For Go applications/CLIs:

  • Installation methods — pre-built binaries (GoReleaser), go install, Docker images, Homebrew...
  • CLI help text — make --help comprehensive; it's the primary documentation
  • Configuration docs — document all env vars, config files, CLI flags

See Application Documentation for details.

Step 8: API Documentation

If your project exposes an API:

API StyleFormatTool
REST/HTTPOpenAPI 3.xswaggo/swag (auto-generate from annotations)
Event-drivenAsyncAPIManual or code-gen
gRPCProtobufbuf, grpc-gateway

Prefer auto-generation from code annotations when possible. See Application Documentation for details.

Step 9: AI-Friendly Documentation

Make your project consumable by AI agents:

  • llms.txt — add a llms.txt file at the repository root. Copy the template from templates/llms.txt. This file gives LLMs a structured overview of your project.
  • Structured formats — use OpenAPI, AsyncAPI, or protobuf for machine-readable API docs.
  • Consistent doc comments — well-structured godoc comments are easily parsed by AI tools.
  • Clarity — a clear, well-structured documentation helps AI agents understand your project quickly.

Step 10: Delivery Documentation

Document how users get your project:

Libraries:

go get github.com/{owner}/{repo}

Applications:

# Pre-built binary
curl -sSL https://github.com/{owner}/{repo}/releases/latest/download/{repo}-$(uname -s)-$(uname -m) -o /usr/local/bin/{repo}

# From source
go install github.com/{owner}/{repo}@latest

# Docker
docker pull {registry}/{owner}/{repo}:latest

See Project Docs for Dockerfile best practices and Homebrew tap setup.

发现问题?提交给管理员复核

评分:

评论 (0)

暂无评论,成为第一个评论者吧!