golang-documentation

Generates and reviews godoc comments, READMEs, changelogs, and llms.txt files for Go projects.

1|Updated May 25, 2020
One-click install
npx skills add https://github.com/titaneric/dotfiles --skill golang-documentation-titaneric
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: golang-documentation
Source: https://github.com/titaneric/dotfiles/tree/main/dot_agents/skills/golang-documentation
Command: npx skills add https://github.com/titaneric/dotfiles --skill golang-documentation-titaneric

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve? Go projects often ship with missing, inconsistent, or paraphrasing documentation that fails both human readers and AI agents. This Skill provides a complete documentation workflow covering godoc comments, README structure, CONTRIBUTING guides, changelogs, API docs, and AI-friendly llms.txt files. ## Core Features & Use Cases - Doc Comment Standards: Enforces godoc conventions where comments explain why and when, not what, with Parameters, Returns, error cases, Deprecated markers, and Playground links. - Project Documentation Templates: Provides ready-to-use templates for README.md (with exact section ordering), CONTRIBUTING.md (10-minute setup rule), CHANGELOG.md (Keep a Changelog format), and llms.txt. - Library vs Application Detection: Adapts documentation strategy based on project type, covering ExampleXxx test functions and pkg.go.dev for libraries, and CLI help text plus installation methods for applications. - Use Case: When auditing a Go repository before release, the Skill reviews every exported symbol's doc comment, reorders the README sections, moves security fixes into the correct changelog category, and generates an llms.txt for AI discoverability. ## Quick Start Ask the agent to review and improve the documentation of your Go project, including doc comments, README, and changelog.

Frequently Asked Questions about golang-documentation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write good godoc comments for Go functions?

Start the comment with the function name followed by a verb phrase, then explain why the function exists, when to use it, and what can go wrong. Include Parameters and Returns sections, document every error case, and add a tab-indented Example block.

What sections should a Go library README have?

Follow this order: title, badges, one-to-two sentence summary, demo code snippet, Getting Started with installation, a detailed Features section, Contributing, and License. Badges typically cover Go version, license, CI status, coverage, and pkg.go.dev reference.

Should I use swaggo/swag to document a gRPC API?

No, swaggo/swag generates OpenAPI specs from Go HTTP handler annotations and does not understand protobuf. For gRPC, write comments directly in the proto files, which serve as the source of truth, and use buf for linting and breaking change detection.

When should a Go package use a doc.go file?

Use doc.go when the package has three or more files or the package comment exceeds roughly ten lines. For small packages with one or two files, place the package comment at the top of the main .go file instead.

Do Go test functions need doc comments?

No, standard TestXxx and BenchmarkXxx functions should not have doc comments because their names are designed to be self-descriptive. Documentation coverage tools do not count test functions, so adding comments there adds noise without value.

How do I make my Go library discoverable by AI coding assistants?

Add an llms.txt file at the repository root summarizing the project, key concepts, API reference, and common patterns. Also register the library with platforms like Context7, DeepWiki, OpenDeep, and zRead, and keep doc comments well structured.