Golang Documentation
Write or audit Go project documentation—godoc, README, CONTRIBUTING, CHANGELOG, examples, and llms.txt—with a consistent technical-writer checklist.
Overview
golang-documentation is an agent skill most often used in Build (also Ship review) that writes and audits Go documentation across godoc, README, CONTRIBUTING, CHANGELOG, and llms.txt.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-documentationWhat is this skill?
- Covers godoc comments, README, CONTRIBUTING, CHANGELOG, Go Playground, Example tests, API docs, and llms.txt
- Write mode: sequential Step 2 checklist or parallelize across packages via sub-agents
- Review mode: up to 5 parallel sub-agents—one per documentation layer
- Triggers for libraries and applications/CLIs alike
- Requires go, golangci-lint, and git tooling per skill metadata
- Review mode uses up to 5 parallel sub-agents for documentation layers
- Write mode follows the Step 2 sequential checklist (or parallel per package)
Adoption & trust: 3.8k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your Go repo ships features fast but godoc, README, and contributor docs are incomplete, stale, or inconsistent across packages.
Who is it for?
Solo Go maintainers preparing OSS releases, internal CLIs, or modules where llms.txt and Example tests matter for adoption.
Skip if: Non-Go codebases, teams that only need a one-line README with no API surface, or projects with no willingness to run go/golangci-lint locally.
When should I use this skill?
Writing or reviewing Go doc comments, README, CONTRIBUTING, CHANGELOG, examples, doc sites, llms.txt, or documentation best practices for libraries and apps/CLIs.
What do I get? / Deliverables
Documentation layers are filled or audited against a Go technical-writer checklist so newcomers and agents can understand the API without reading every file.
- Updated godoc comments and Example tests
- README, CONTRIBUTING, CHANGELOG, and optional llms.txt aligned to project style
- Review findings per documentation layer in Review mode
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is authored while the product is built, but review passes recur before release—Build/docs is the first shelf where godoc and README work typically starts. The skill explicitly targets doc comments, project docs, Example tests, API docs, and llms.txt—not CI, tests, or feature code.
Where it fits
Fill missing godoc and README after adding a new public package to an indie SaaS backend module.
Run Review mode with five doc-layer sub-agents before tagging a CLI release.
Add Example tests and Go Playground snippets so API docs match actual behavior.
Finalize CHANGELOG and CONTRIBUTING so open-source contributors can onboard pre-launch.
How it compares
Structured Go documentation workflow—not a generic markdown linter or unrelated Swagger-only OpenAPI generator.
Common Questions / FAQ
Who is golang-documentation for?
Go library and application authors using Claude Code or similar agents who want example-driven godoc, project docs, and llms.txt maintained like production code.
When should I use golang-documentation?
Use it in Build when adding packages or examples; in Ship when reviewing doc accuracy before release; whenever triggers mention doc comments, CONTRIBUTING, CHANGELOG, or documentation best practices.
Is golang-documentation safe to install?
It can Read, Edit, Write, run go and golangci-lint, and use git—review the Security Audits panel on this Prism page before granting those tools in your environment.
SKILL.md
READMESKILL.md - Golang Documentation
**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. **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. ## 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](./references/library.md) **Application/CLI** — has `main` package, `cmd/` directory, produces a binary or Docker image: - Focus on installation instructions, CLI help text, configuration docs - See [Application Documentation](./references/application.md) **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): | 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... ## 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