Document

Input

• A feature, behavior, module, command, API, release, operational procedure, or existing doc.
• Use explicit input first; otherwise infer from context, recent edits, selected files, or branch.
• Safest default: ask only when audience, ownership, or location is unclear.

Workflow

1. Identify audience and purpose. Know whether the reader is a user, integrator, contributor, operator, maintainer, or future agent.
2. Choose the owner. Update the closest existing doc. Create a new doc only when audience, lifetime, or ownership clearly differs.
3. Verify behavior. Read relevant code, tests, config, scripts, schemas, and existing docs before writing.
4. Separate facts by owner. Product behavior, external contracts, repo workflows, and system mechanics should not duplicate each other.
5. Update cleanly. Keep docs scannable, concise, and current. Avoid parallel explanations that will drift.
6. Use examples sparingly. Prefer runnable commands, realistic config, checked snippets, and links to authoritative code or tests.
7. Prune stale content. Remove outdated docs, dead links, obsolete examples, and temporary review artifacts discovered nearby.
8. Validate. Check links, commands, snippets, paths, generated output, and any spec/doc sync mechanism where practical.