From design-system-ops-internal
Report design-system adoption — coverage (of surfaces that could use the system, how many do) reported SEPARATELY from adoption (the usage trend) — with at-risk areas flagged and a baseline established on first run. Triggers on 'adoption report', 'how widely is the design system used', 'which areas are lagging on the design system', 'coverage report'. Do NOT trigger for component library health/quality — use component-audit. Do NOT trigger for a leadership business brief — use stakeholder-brief.
How this skill is triggered — by the user, by Claude, or both
Slash command
/design-system-ops-internal:adoption-reportThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Measures whether the system is actually used, keeping **coverage** and **adoption** strictly
Measures whether the system is actually used, keeping coverage and adoption strictly separate (see adoption-measurement). On the first run it establishes a baseline rather than inventing a trend. At-risk areas are framed as enablement opportunities, not team failings.
Reads (all optional): target_repo; stack.component_roots; output.trend_dir (for
baseline/trend via session-memory); severity_overrides.
None required. If GitHub is configured, MAY use history to compute the adoption trend; without it, report coverage only and note the limitation.
If there's no prior snapshot, this is a baseline run: compute coverage, save it (via
session-memory), and say explicitly that trend will appear next run. Don't fabricate a trend.
Of the surfaces that could use the system, how many do: shared-component usage vs page-local one-offs that duplicate a shared atom; token usage vs raw values. Break down by area (route/feature folder).
Direction over time per area: moving toward or away from the system. Requires prior snapshots or git history; otherwise mark N/A.
Areas with low shared usage and high local one-offs — most likely to drift, best ROI for enablement (docs, onboarding, comms).
## Adoption Report — <repo> [baseline | trend since <date>]
**<🟢/🟡/🟠/🔴> Headline.** <Coverage posture + the area to help first.>
### Coverage (today)
| Area | Shared usage | One-offs | Coverage |
|------|--------------|----------|----------|
| jobs | 41 imports | 3 | 🟢 |
| care-journeys | 12 | 9 | 🟠 |
### Adoption (trend)
<per-area direction — or "baseline run, no trend yet">
### At-risk areas
- <area> — low shared usage + high one-offs → enablement: <docs/onboarding/comms>
### Scope
- Inspected: <areas, import scan>
- Not inspected: runtime usage analytics
- Assumed: baseline on first run; trend needs history
Coverage and adoption answer different questions — a high-coverage area still drifting is a different problem from a low-coverage area improving. Keep them apart, and treat at-risk areas as places to help, not to name and shame.
npx claudepluginhub quadrivia-ai/design-system-ops-internal --plugin design-system-ops-internalSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.