/docs-coverage

name: docs-coverage
description: "Audit whether a design system's documentation surface keeps pace with its component library — coverage gaps (components with no docs), staleness (docs that predate the component's last code change), and orphaned docs. Works with zero integration from the codebase and a Storybook build; Zeroheight, Supernova, and custom docs sites are optional layers. Trigger when someone says: docs coverage, documentation audit, are our docs up to date, which components are undocumented, is our documentation keeping pace, stale docs check, documentation health, Storybook coverage, or anything about whether the documentation surface matches the components. Do NOT trigger for WRITING documentation — use usage-guidelines, pattern-documentation, token-documentation, or ai-component-description for that. Do NOT trigger for general system health (use system-health) or for documentation usage/analytics (use adoption-report)."
references:
  - ../../knowledge-notes/documentation-coverage.md
  - ../../knowledge-notes/output-discipline.md
  - ../../knowledge-notes/adoption-measurement.md

Docs coverage

A skill for auditing whether a design system's documentation surface keeps pace with its components. It measures the code (the source of truth for what exists) against each documentation surface and reports three things: **coverage gaps** (components with no documentation), **staleness** (documentation that predates the component's last code change), and **orphaned docs** (pages for components that no longer exist). Produces a severity-rated finding table with per-signal confidence labelling.

Context

Code is the source of truth for what components exist; the documentation surface is measured against it. A component in code with no docs is a coverage gap; a page for a deleted component is an orphan; a page older than the component's last change is a staleness risk.

This skill is built to work with **no integration at all**: a components directory plus a Storybook build plus git history answer coverage and staleness for most teams. Hosted platforms (Zeroheight, Supernova, custom docs sites) are optional layers that light up when configured — never prerequisites. The audit never blocks on an integration; it logs what is unavailable and proceeds with what it can reach.

The hard part is trust. Coverage is a join between two lists — components in code and entries in the doc surface — and the join is only as reliable as the key that links them. Every coverage finding carries a confidence tier so a fuzzy guess is never presented as a fact. See `documentation-coverage.md` for the full model.

---

Configuration

Before producing output, check for a `.ds-ops-config.yml` file in the project root. If present, load:

• `system.framework` — affects how component files are discovered (e.g. `.tsx` / `.vue` / `.twig`)
• `severity.*` — severity-rating overrides, applied the same way the other audit skills apply them
• `integrations.storybook.static_path` — local Storybook build directory (e.g. `storybook-static`); the preferred source
• `integrations.storybook.url` — published Storybook URL for pulling `/index.json` when no local build exists
• `integrations.documentation` — optional hosted platform: `platform`, `url`, `api_key_env`, plus `styleguide_id` (Zeroheight) or `design_system_id` (Supernova)
• `integrations.github` — if enabled, used to read change history when the audit runs outside a local clone
• `docs_coverage.staleness_threshold_days` — grace window before a doc is flagged stale (default 90)
• `recurring.*` — if this is a recurring run, load the previous report for trend comparison

If no config file exists, proceed with defaults and codebase discovery.

Auto-pull integrations

If integrations are configured, pull data automatically before asking the user for manual input.

**Storybook — the primary surface (`integrations.storybook.enabled: true` or a local build):**

• Prefer a local static build: read the index from `integrations.storybook.static_path` (default `storybook-static/index.json`). No server, no auth.
• If only a URL is configured, fetch `<url>/index.json`.
• Branch on the top-level `v` field, which tracks the Storybook version: `v: 3` is the SB 6 `stories.json` (entries under the `stories` key); `v: 4` and `v: 5` are the SB 7+ `index.json` (entries under `entries`), and `v: 5` (SB 8.1+) adds `componentPath`. `componentPath` is opt-in and not guaranteed even on recent Storybook — use it for the Tier A join when present, and **fall back to the Tier B name join whenever it is absent, regardless of `v`**.
• The official Storybook MCP (`@storybook/addon-mcp`) is **optional** — at the time of writing it needs a running server and is React-only/experimental. Use it only if the tools are already available; never make it a dependency.

**Documentation platform — optional layers (`integrations.documentation.enabled: true`):**

• `zeroheight`: use the REST API (Enterprise) — `GET /styleguides/{id}/pages` and `GET /pages/{id}` give the documented-page set and `updated_at` per page (high-confidence staleness). There is no components endpoint, so reconstruct the coverage diff by name-matching pages against the code/Storybook inventory (Tier C).
• `supernova`: use the MCP "Relay" or `@supernovaio/sdk` — `get_design_system_component_list` vs `get_documentation_page_list` gives a coverage diff (heuristic link, Tier B/C). Per-page staleness timestamps are not reliably exposed — mark staleness unknown unless a page timestamp is actually present.
• `custom`: crawl the sitemap or rendered HTML for page titles; name-match only (Tier C).

If an integration is configured but fails (auth, rate limit, missing build), log the failure and fall back to the codebase-only baseline. Never block the audit because a platform is unavailable.

Step 0: Build the component inventory (the source of truth)

Establish what components exist before looking at any documentation.

1. If a `code