triage

Scans your system’s size, stack, token maturity, and documentation state. Classifies it into one of four states – new, growing, established, or legacy – and produces a prioritised run plan: which 3–5 skills to run first, which to skip, and which to return to later. The answer to “I just installed this, where do I start?”

token-audit

Reads your token files – JSON, SCSS, CSS custom properties, Tailwind config, whatever you’ve got – and produces a structured report: naming violations, missing semantic tiers, wrong-tier references, DTCG alignment gaps, and architectural debt. Not a list of suggestions. A prioritised finding set with severity, location, and recommended fix.

component-audit

Inventories your component library with usage signals, duplication analysis, and coverage gaps. Counts what you have, flags what’s redundant, identifies what’s missing, and scores AI-readiness across the library. Produces a component-by-component assessment, not a summary paragraph.

system-health

Scores your design system across 7 dimensions – tokens, components, documentation, adoption, governance, AI readiness, and platform maturity – calibrated to your system’s maturity level. A Level 2 system isn’t scored against Level 4 expectations.

drift-detection

Finds where consuming teams have diverged from the system and classifies why. Five drift types: intentional divergence, version lag, accidental drift, misunderstanding, and system gap. Each finding includes the team, the component, the divergence, and the classification – so you know whether to fix the system, fix the team, or accept the difference.

naming-audit

Audits naming conventions across components, tokens, and patterns. Checks for consistency, semantic clarity, and convention violations. Catches the kind of naming drift that compounds silently – btn vs button, color-primary vs brand-primary, modal vs dialog – and produces a unified recommendation.

contribution-workflow

Produces a complete 6-stage contribution process: proposal, design, build, documentation, community review, and release. Includes templates for each stage, capacity calibration based on team size, and clear criteria for what gets accepted vs. what gets sent back. Not a philosophy document. An operational workflow.

deprecation-process

Produces a full deprecation plan: blast radius analysis showing every consuming team and component affected, migration path with code examples, communication timeline, and sunset date recommendation. Tells you who will break, how badly, and what to give them instead.

decision-record

Captures architectural decisions with the context that produced them. Problem statement, options considered, trade-offs evaluated, decision made, and consequences accepted. The kind of record that prevents the next team from re-litigating the same decision in six months because nobody wrote down why.

change-communication

Produces the full communication package for a design system change: release notes, migration guide, and team announcement – all scaled to impact level. A minor token rename gets a changelog entry. A breaking component API change gets a migration guide with before/after code examples and a timeline.

ai-component-description

Generates a six-section component description optimised for Figma’s MCP server and LLM consumption. Not a README – a machine-readable specification that tells AI tooling what the component does, when to use it, what props it accepts, and how it composes. Includes diagnostic mode: if the component lacks sufficient metadata to document well, produces a remediation brief instead of thin documentation.

pattern-documentation

Documents recurring UI patterns – not individual components, but the composed behaviours they form. State coverage, accessibility considerations, composition rules, and related patterns. Includes diagnostic mode for patterns that aren’t mature enough to document yet.

token-documentation

Documents token intent, not just token values. Organised by tier – primitive, semantic, component – with theming contracts, usage context, and do/don’t examples. Includes diagnostic mode for token systems that are too incomplete or inconsistent to document meaningfully.

usage-guidelines

Writes component usage documentation: when to use it, when not to, edge cases, and anti-patterns. Anti-patterns derived from actual misuse evidence in the codebase, not hypothetical scenarios. Includes diagnostic mode for components that lack sufficient usage data to produce meaningful guidelines.

design-to-code-check

Compares your design specification against its code implementation across 5 dimensions: visual fidelity, layout structure, responsive behaviour, interaction states, and token usage. Classifies every discrepancy – implementation error, spec gap, system inconsistency, or accepted divergence. Dual scoring separates how well the check ran from how well the code matches the design.

accessibility-per-component

Audits a component across five dimensions: keyboard navigation, screen reader announcement, colour contrast, focus management, and ARIA implementation. Maps each finding to specific WCAG 2.1 AA criteria with severity and remediation. Dual scoring separates how thorough the audit was from how accessible the component actually is.

token-compliance

Scans your codebase for hardcoded values that should be tokens, wrong-tier token references, and inconsistent token application. Every finding includes the file, line, current value, and recommended token. Dual scoring separates how thoroughly the scan ran from how compliant the codebase actually is.