happier-docs

# Happier Documentation Keep documentation truthful, useful, current, and owned without turning every code change into prose churn. Follow the root constitution and, for published docs, `apps/docs/AGENTS.md`. For an explicit deep review or QA request, use `skills/happier-review` as the orchestrator and apply this skill as the documentation-domain standard; this skill does not create a competing general review workflow. ## 1. Classify the documentation impact For the changed behavior or contract, decide whether it affects: - internal technical/product architecture under `docs/**`; - published user/operator/self-hoster/contributor behavior under `apps/docs/content/docs/**`; - both surfaces; - neither surface, with a concrete reason. A refactor that leaves every documented contract unchanged may need no docs edit. A behavior, command, setting, support status, workflow, failure/recovery path, protocol, persistence shape, compatibility rule, deployment requirement, or canonical owner change normally does. ## 2. Identify audience, page type, and canonical owner Classify published pages as task guide, concept, reference, troubleshooting, or development documentation. Internal docs explain architecture, contracts, ownership, and contributor-facing implementation constraints. Search by the feature, command, setting, route, schema, provider/agent id, UI label, error, and reader phrasing before creating a page. Update, move, consolidate, or retire the canonical page instead of a...