document-codelisted

Write and improve code documentation. Use whenever asked to document code, add comments, write a doc comment, annotate a function, document a package, explain a file's purpose, or clean up unclear or outdated comments — however phrased ("doc this"). Applies to Go, Bash/shell, YAML, Svelte, SQL, TypeScript, and other source or config files. Invoke before writing any documentation, even for one function.
a-novel-kit/stack · ★ 1 · Data & Documents · score 67

Install: claude install-skill a-novel-kit/stack

# Code Documentation Skill This skill governs how to write, improve, and maintain code documentation. Help the reader understand **what** something does and **how to use it**, not how it is implemented. **Document at the element level.** Every exposed element — type, function, target, value, field — documents itself directly; never describe elements in an aggregate block above them. A section header listing its targets, a type doc enumerating its variants, a struct doc itemizing its fields all put the doc in the wrong place: the reader looks at the element and finds no comment, while the description sits paragraphs above with all the others. This applies everywhere — pnpm scripts, enum values, interface methods, struct fields. --- ## What to Document Document these file types: - **Language source files**: `.go`, `.ts`, `.svelte`, `.sql`, `.sh`, `.bash`, `.proto`, etc. - **General configuration files**: `.yaml`, `.toml`, `.json` (when they encode project logic, not tool config) Do **not** document these: - Tool-specific configuration files: `.golangci.yaml`, `.eslintrc`, `.prettierrc`, `renovate.json`, etc. Their documentation belongs to the tool, not the codebase. - Auto-generated files (protobuf output in `protogen/`, mocks, migrations generated by tooling). For `.proto` files, the comment conventions on `service`, `rpc`, `message`, `field`, and `enum` values belong to the **`write-proto` skill**: apply this skill's general principles (accuracy, no redundancy, int