write-docslisted

# write-docs Pick the artifact, read that file, then write. Do not load more than one — the conventions differ and mixing them produces documents that serve nobody. | Writing… | Read | Reader you are serving | |---|---|---| | A README for a public lib, CLI, or agent tool | [READMES.md](READMES.md) | someone deciding in 30 seconds whether to use this | | A developer guide, tutorial, runbook, migration, or deprecation | [GUIDES.md](GUIDES.md) | someone trying to complete a task without guessing | | CLI flags, subcommands, `--help`, error text, output contracts | [CLI.md](CLI.md) | someone typing at a prompt, and the script that wraps them | | Code comments, docstrings, inline rationale | [COMMENTS.md](COMMENTS.md) | the maintainer reading this during an outage | | `AGENTS.md` / `CLAUDE.md` operating guides | [AGENTSMD.md](AGENTSMD.md) | an agent with no memory of your project | | Commit messages, PR descriptions, changelog entries | [PR.md](PR.md) | a maintainer running `git log` in two years | Not this skill: design docs, ADRs (use `grill-me`), internal service wikis, or authoring a skill (use `write-skill`). ## Workflow 1. Read the implementation, schema, tests, `--help`, or diff that establishes the facts. 2. Name the reader and the action this document must enable. 3. Choose one canonical term for each repeated concept. Preserve exact API names and identifiers. 4. Draft through the selected artifact lens. 5. Check that every claim, command, caveat, and boundary still m