Documentation

Produce and maintain user- and developer-facing documentation so others can understand, use, and operate the system.

Why this matters: Good docs are the contract between "how it works today" and the next person (or future you). They cut onboarding time and reduce "how do I run this?" and "where’s the deploy runbook?"—whether the project is a CLI, a service, or a monorepo. Accuracy and clarity beat perfection; update docs with the code so they don’t drift.

When to Activate

• User asks for README, API docs, runbook, or "document this"
• Adding or changing public APIs, config, or env vars
• Onboarding: setup, architecture, or operational procedures
• After implementing a feature that needs user- or ops-facing docs

Core Principles

• Accuracy — Docs must match current behavior and config. Update docs in the same change as code/config when possible.
• Audience — Match tone and depth to the reader (new dev, ops, external API consumer).
• Discoverability — README is the entry point; link to API docs, runbooks, and contributing. Avoid orphan pages.
• Actionable — Procedures should be step-by-step; code examples should run (or state prerequisites).