golang-documentation

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

Updated Jun 8, 2026
One-click install
npx skills add https://github.com/vovanostm-public/multica --skill golang-documentation-vovanostm-public
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: golang-documentation
Source: https://github.com/vovanostm-public/multica/tree/main/docs/wiki/architecture/archived-codex-skills/20260525-190000/golang-documentation
Command: npx skills add https://github.com/vovanostm-public/multica --skill golang-documentation-vovanostm-public

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 restating-the-code documentation. This Skill provides a complete documentation workflow for Go libraries and applications, covering godoc comments, README structure, CONTRIBUTING, CHANGELOG, Example tests, 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: Ships ready-to-use README, CONTRIBUTING, CHANGELOG, and llms.txt templates with a prescribed section order and the 10-minute contributor setup rule. - Project-Type Detection: Distinguishes libraries from applications/CLIs and applies the right documentation strategy, including ExampleXxx tests, Go Playground demos, OpenAPI/AsyncAPI/protobuf API docs, and architecture decision records. - Use Case: Ask the agent to audit a Go repository's documentation; it will detect the project type, fix doc comments across packages in parallel, reorder the README, and generate a CHANGELOG and llms.txt. ## Quick Start Ask the agent to review and complete the documentation for your Go repository, 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 project README include?▼

Follow this order: Title, Badges, Summary, Demo, Getting Started, Features, Contributing, and License. The Features section should be the longest, and badges typically cover Go version, license, CI status, coverage, and Go Report Card.

Should I create a doc.go file for my Go package?▼

Only for packages with three or more files or a package comment longer than about ten lines. For small packages, place the package comment at the top of the main .go file instead.

How do I document a gRPC API in Go?▼

Add comments directly to proto messages, services, and RPCs since protobuf files are the source of truth. Use buf for linting and breaking change detection; swaggo/swag only works for REST APIs, not gRPC.

What is llms.txt and does my Go library need one?▼

llms.txt is a file at the repository root giving LLMs a structured overview of your project, including key concepts, API reference, and common patterns. It is recommended for both libraries and applications to make projects AI-friendly.

Where do security fixes go in Keep a Changelog format?▼

Security fixes belong in a dedicated ### Security section, separate from ### Fixed. Keep a Changelog defines Security as its own top-level category alongside Added, Changed, Deprecated, Removed, and Fixed.