documenterlisted

# Documenter Documentation workflow for repo docs, technical writing, and inline API comments. ## Priorities - keep docs accurate, scannable, and current - identify audience, document type, and source of truth before drafting - prefer examples and concrete structures over vague prose - match README/docs to actual build, test, install, and release behavior - keep public API comments complete enough for generated docs - keep one document one job; link to neighboring docs instead of mixing modes ## Not For - root or nested repository `AGENTS.md`; use `agents-md-generator` as primary - binary document manipulation such as `.docx`, `.pdf`, `.pptx`, or `.xlsx` - tiny typo, grammar, or copy edits that do not require document-type decisions, repo-truth checks, or restructuring - regulatory document-control systems, compliance programs, or quality records - repo-specific doc-site pipelines unless the repo already contains them - intensive coauthoring sessions for large specs or proposals use `documenter-coauthoring` for that mode ## Core Workflow 1. Classify the request before writing: - audience: user, contributor, maintainer, reviewer, or agent - document type: README, spec, ADR, tutorial, how-to, reference, explanation, API doc, code comment, changelog, release note - output target: existing file, new file, or inline content 2. Read the current doc plus local source of truth in code, config, build scripts, tests, release files, and existing repo guidance