# Docs Writer

> Keeps documentation in sync with the code: README, usage and related docs when a public API or behavior changes. Leaves no dead or misleading docs behind.

- Skill: `byerlikaya/docs-writer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add byerlikaya/docs-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/byerlikaya/docs-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: byerlikaya (https://skillmd.com/u/byerlikaya)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/byerlikaya/docs-writer

---


# Documentation

<!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside
     Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions
     truncated or dropped, which strips the very keywords a match depends on. -->
Trigger phrases: "documentation", "docs", "update README", "API docs", "write docs", "document it", "write usage"

Goal: the docs must **match the code**. Wrong/stale docs are worse than no docs (they inspire trust and mislead).
Trigger: when a public API, command, configuration, or user-visible behavior changes.

## When it is mandatory
- A public function/endpoint/CLI signature or behavior changed.
- A new feature, configuration key, or environment variable was added.
- The install/run steps changed.
- A breaking change was made (also coordinate via `release`/CHANGELOG).

## Checklist
- [ ] Docs are up to date for the changed public surface
- [ ] Examples **work** (copy-paste tested / mentally traced)
- [ ] Dead/misleading wording removed (no leftover old name/parameter)
- [ ] New configuration/env documented (default + whether required)
- [ ] Scope minimal — not a repetition of the code, but "why/how to use it"
- [ ] No secret/real credential in the docs (use a placeholder)

## How
1. **Identify the changed surface** — extract the public signature/behavior diff from the diff.
2. **Find the right doc** — README, `docs/`, docstring, OpenAPI, command `--help`. If there is more than one, update them all.
3. **Write**: what it does · how it is called (example) · input/output · limits/error cases. Short and correct.
4. **Verify the examples** — does the command/code example actually run.
5. **Clean up the old** — delete references to removed APIs/parameters.
6. **Translation**: if the user-visible doc is multilingual, coordinate with `i18n-integrity`.

## Principles
- **Single source** — behavior lives in the code; the doc *explains* it, does not copy it (a copied doc goes stale).
- **Example > paragraph** — a working example beats three paragraphs.
- **Minimal** — don't write a giant doc no one will maintain; answer the most-asked question.

## Co-authoring a longer doc (guide, tutorial, README rewrite)
For a substantial doc the content lives in the author's head, not the diff — don't guess it. Interview for intent
and audience, draft in passes, and let the user steer before you polish. The collaborative workflow (audience/intent
questions, outline-first, section-by-section drafting, revision loop): **`references/coauthoring.md`**.

## Invariant rules
1. **Correctness > completeness** — don't write a wrong doc; if unsure, flag it/ask.
2. **Examples must work.**
3. **Leave no stale/dead docs.**
4. **No secret/real credential** — use a placeholder (aligned with §4).
5. **Don't repeat the code** — don't just copy the signature; explain the usage.