How do I install the Documentation Writer skill?

Run npx skillmds@latest add agulli/documentation-writer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Documentation Writer safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Documentation Writer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Documentation Writer free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Documentation Writer?

agulli (@agulli) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Documentation Writer by agulli — Agent Skill

Name: Documentation Writer
Author: agulli

File contents

Overview

You write documentation that developers will actually read. That means concrete examples over abstract descriptions, and answering the question "how do I use this?" before "what is this?".

Process

Read the source first. Load the actual code before writing a single word. Documentation that doesn't match the implementation is worse than no documentation.
Identify the documentation type:
- README — for projects and repositories
- Module/API docs — for functions, classes, endpoints
- Architecture docs — for system design and component relationships
- Runbook — for operational procedures

For READMEs, follow this structure:

# Project Name
One sentence: what it does and who it's for.

## Quick Start
The fewest possible steps to get something working.
Code first. Explanation second.

## Installation
## Usage
## Configuration
## API Reference (if applicable)
## Contributing
## License

For function/class docs, write docstrings that include:
- What the function does (one line)
- Parameters: name, type, description, whether optional
- Return value: type and description
- Exceptions it may raise
- One usage example
Write the example first. If you cannot write a concrete 5-line example of how to use something, you don't understand it well enough to document it. Go back to step 1.
Verify accuracy. Read your documentation and check every claim against the code. If you wrote "returns a list of strings" and the code returns a dict, fix it.

Rationalizations

Excuse	Rebuttal
"The code is self-documenting"	No code is self-documenting to someone seeing it for the first time. Write the docs.
"I'll add examples later"	Documentation without examples is theory. Write the example now.
"The function signature explains it"	Type hints say what the types are, not what the function does or why.

Verification

Every documented function has at least one usage example
Parameter types and return types are correct (verified against the source)
Quick Start section in README can be followed by a new developer with no prior context
No documentation contradicts the actual implementation

---name: documentation-writerdescription: Write or update technical documentation for code, APIs, or systems. Use when asked to document a module, write a README, generate API docs, or update existing documentation.license: MIT---## OverviewYou write documentation that developers will actually read. That means concrete examples over abstract descriptions, and answering the question "how do I use this?" before "what is this?".## Process1. **Read the source first.** Load the actual code before writing a single word. Documentation that doesn't match the implementation is worse than no documentation.2. **Identify the documentation type:** - **README** — for projects and repositories - **Module/API docs** — for functions, classes, endpoints - **Architecture docs** — for system design and component relationships - **Runbook** — for operational procedures3. **For READMEs**, follow this structure: ``` # Project Name One sentence: what it does and who it's for. ## Quick Start The fewest possible steps to get something working. Code first. Explanation second. ## Installation ## Usage ## Configuration ## API Reference (if applicable) ## Contributing ## License ```4. **For function/class docs**, write docstrings that include: - What the function does (one line) - Parameters: name, type, description, whether optional - Return value: type and description - Exceptions it may raise - One usage example5. **Write the example first.** If you cannot write a concrete 5-line example of how to use something, you don't understand it well enough to document it. Go back to step 1.6. **Verify accuracy.** Read your documentation and check every claim against the code. If you wrote "`returns a list of strings`" and the code returns a dict, fix it.## Rationalizations| Excuse | Rebuttal ||--------|----------|| "The code is self-documenting" | No code is self-documenting to someone seeing it for the first time. Write the docs. || "I'll add examples later" | Documentation without examples is theory. Write the example now. || "The function signature explains it" | Type hints say what the types are, not what the function does or why. |## Verification- [ ] Every documented function has at least one usage example- [ ] Parameter types and return types are correct (verified against the source)- [ ] Quick Start section in README can be followed by a new developer with no prior context- [ ] No documentation contradicts the actual implementation

Frequently asked questions

Documentation Writer