What problem does it solve?
Keeping Happier's internal technical docs and published user/operator documentation accurate is hard: behavior changes silently invalidate pages, hand-written reference tables drift from code, and pages get orphaned from navigation. This Skill provides a disciplined workflow for classifying documentation impact, establishing product truth from code evidence, and validating edits before they ship.
Core Features & Use Cases
- Impact classification and canonical ownership: Decide whether a change affects
docs/**, apps/docs/content/docs/**, both, or neither, and update the single canonical page instead of creating parallel explanations.
- Evidence-backed product truth: Verify claims against implementing code, feature gates (
uiFeatureRegistry.ts, features/catalog.ts), and release artifacts, distinguishing shipped, preview, experimental, and planned behavior.
- Generation over hand-writing: Prefer generated reference pages via
apps/docs/scripts/generateReference.mjs so drift fails the build instead of shipping.
- Validation contract: Run
check:content, tests, type checks, and builds to catch broken links, orphaned pages, and stale code-derived lists.
- Use Case: After adding a new CLI flag to the Happier CLI, use this Skill to find the canonical settings page, verify the flag's gate and default in code, update the generated reference, and run
yarn --cwd apps/docs check:content to confirm nothing breaks.
Quick Start
Use the happier-docs skill to update the published documentation for the feature I just changed and validate the docs build.