happier-docs

Create, update, and validate Happier internal and published documentation with evidence-backed claims.

1.6k|141|Updated Dec 16, 2025
One-click install
npx skills add https://github.com/happier-dev/happier --skill happier-docs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: happier-docs
Source: https://github.com/happier-dev/happier/tree/main/skills/happier-docs
Command: npx skills add https://github.com/happier-dev/happier --skill happier-docs

SYSTEM DOCUMENTATION & REQUIREMENTS

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.

Frequently Asked Questions about happier-docs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update Happier documentation after a code change?

Classify whether the change affects internal docs under docs/**, published docs under apps/docs/content/docs/**, both, or neither. Then update the canonical page for that feature rather than creating a parallel page, and run yarn --cwd apps/docs check:content to validate links and structure.

How do I verify a documentation claim about Happier behavior?

Inspect the reachable implementing producer and consumer code, not just matching strings or README statements. Identify gates, defaults, platform variation, and release basis from immutable release artifacts, and distinguish shipped, preview, experimental, and planned behavior.

When should Happier docs use generated reference pages?

Use generation whenever the same list exists as structured data, such as agent capabilities, feature flags, keyboard shortcuts, or download links. The apps/docs/scripts/generateReference.mjs registry defines what is generated, and generated pages fail the build on drift instead of shipping stale content.

What validation commands does the Happier docs workflow require?

Run yarn --cwd apps/docs check:content for links and structural rules, yarn --cwd apps/docs test for guardrails, types:check for MDX and TypeScript changes, and build when routing, navigation, or generation behavior is affected.

When does a code change not require documentation edits?

A refactor that leaves every documented contract unchanged may need no docs edit. Changes to behavior, commands, settings, support status, workflows, failure paths, protocols, or canonical ownership normally do require edits.