Write and review documentation for Go libraries and applications, from code comments and README files to installation guides and changelogs. Add runnable examples and structured project summaries that help readers and AI agents understand how to use the code.
中文简介正在准备中。当前显示英语简介。
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.
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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: Fan out the sub-agents described in the "Parallelizing Documentation Work" section (one per package, or one per doc layer/file) for documenting or auditing documentation across a large codebase, and merge their output into the final docs. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.
Modes:
Community default. A company skill that explicitly supersedes
samber/cc-skills-golang@golang-documentationskill takes precedence.
Write documentation that serves both humans and AI agents. Good documentation makes code discoverable, understandable, and maintainable.
samber/cc-skills-golang@golang-naming skill for naming conventions in doc comments.samber/cc-skills-golang@golang-testing skill for Example test functions.samber/cc-skills-golang@golang-project-layout skill for where documentation files belong.samber/cc-skills@humanizer-en-asd-ste100 skill for strict, controlled English prose (ASD-STE100) when documentation demands maximal clarity and unambiguity.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.
For regulated or safety-critical documentation that requires strict controlled-English prose, → See samber/cc-skills@humanizer-en-asd-ste100 skill.
Before documenting, determine the project type — it changes what documentation is needed:
Library — no main package, meant to be imported by other projects:
ExampleXxx functions, playground demos, pkg.go.dev renderingApplication/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.
Every Go project needs these (ordered by priority):
| Item | Required | Library | Application |
|---|---|---|---|
| Doc comments on exported functions | Yes | Yes | Yes |
Package comment (// Package foo...) — MUST exist | Yes | Yes | Yes |
| README.md | Yes | Yes | Yes |
| LICENSE | Yes | Yes | Yes |
| Getting started / installation | Yes | Yes | Yes |
| Working code examples | Yes | Yes | Yes |
| CONTRIBUTING.md | Recommended | Yes | Yes |
| CHANGELOG.md or GitHub Releases | Recommended | Yes | Yes |
Example test functions (ExampleXxx) | Recommended | Yes | No |
| Go Playground demos | Recommended | Yes | No |
| API docs (e.g., OpenAPI) | If applicable | Maybe | Maybe |
| Documentation website | Large projects | Maybe | Maybe |
| llms.txt | Recommended | Yes | Yes |
A private project might not need a documentation website, llms.txt, Go Playground demos...
When documenting a large codebase with many packages, use up to 5 parallel sub-agents for independent tasks:
ExampleXxx test functions for multiple packages simultaneouslyEvery 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.
README SHOULD follow this exact section order. Copy the template from templates/README.md:
# headingCommon badges for Go projects:
[](https://go.dev/) [](./LICENSE) [](https://github.com/{owner}/{repo}/actions) [](https://codecov.io/gh/{owner}/{repo}) [](https://goreportcard.com/report/github.com/{owner}/{repo}) [](https://pkg.go.dev/github.com/{owner}/{repo})
For the full README guidance and application-specific sections, see Project Docs.
CONTRIBUTING.md — Help contributors get started in under 10 minutes, covering prerequisites, clone, build, test, and PR process. If setup takes longer, improve the process with a Makefile, docker-compose, or devcontainer. See Project Docs.
Changelog — Track changes using Keep a Changelog format or GitHub Releases, copying the template from templates/CHANGELOG.md. Write each entry to answer what changed for the reader — internal refactors without user-visible impact belong in commit history, and a fixed edge case never becomes a broad "reliability improvement" claim. See Project Docs.
For Go libraries, add these on top of the basics:
// Play: https://go.dev/play/p/xxx. Use a Go Playground integration when one is available to create and share playground URLs.func ExampleXxx() in _test.go files. These are executable documentation verified by go test.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.See Library Documentation for details.
For Go applications/CLIs:
go install, Docker images, Homebrew...--help comprehensive; it's the primary documentationSee Application Documentation for details.
If your project exposes an API:
| API Style | Format | Tool |
|---|---|---|
| REST/HTTP | OpenAPI 3.x | swaggo/swag (auto-generate from annotations) |
| Event-driven | AsyncAPI | Manual or code-gen |
| gRPC | Protobuf | buf, grpc-gateway |
Prefer auto-generation from code annotations when possible. See Application Documentation for details.
Make your project consumable by AI agents:
llms.txt file at the repository root. Copy the template from templates/llms.txt. This file gives LLMs a structured overview of your project.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.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Measure Go performance by writing benchmarks, examining CPU and memory profiles, and comparing repeated runs with benchstat. Use the results to assess code changes, detect slowdowns in CI, and investigate production performance.
中文简介正在准备中。当前显示英语简介。
Build, extend, or review Go command-line tools with clear commands, flags, and configuration priorities. It guides output formats, exit codes, shell completion, cancellation, and tests so tools behave predictably in scripts and terminals.
中文简介正在准备中。当前显示英语简介。
Make Go code easier to read by reviewing line breaks, variable declarations, branching, function parameters, and file organization. Provides concrete style guidance for implementation, code reviews, and project standards where formatting tools alone cannot judge clarity.
中文简介正在准备中。当前显示英语简介。
Design and review concurrent Go code with clear goroutine ownership, shutdown paths, and error handling. Choose channels, locks, or atomic operations to protect shared data, and structure worker pools with controlled concurrency and cancellation.
中文简介正在准备中。当前显示英语简介。
Design how Go requests carry cancellation signals, time limits, and request metadata through application layers. Helps investigate work that continues after cancellation, choose suitable context types, and separate background tasks from the request lifecycle.
中文简介正在准备中。当前显示英语简介。
Set up or improve GitHub Actions pipelines for Go projects. Configure automated tests, code checks, vulnerability scans, dependency update bots, releases, and Docker publishing, with workflow templates and repository settings that control permissions and merge requirements.
中文简介正在准备中。当前显示英语简介。