sharaf/professional-design-system-architect
Design, build, or audit professional UI design systems across strategy, product language, foundations, tokens, components, patterns, accessibility, content, Figma/code libraries, documentation, QA, governance, adoption, measurement, theming, releases, and migration. Use when the user wants to create a design-system blueprint, review an existing design system, fix design-system drift, plan Figma/code parity, define token or component architecture, evaluate accessibility and governance maturity, or sequence design-system adoption and migration work.
100
100%
Does it follow best practices?
Impact
100%
1.75xAverage score across 3 eval scenarios
Passed
No known issues
audit-workflow.mdreferences/
Audit Workflow
Use this when the user asks to review an existing design system from Figma, Storybook, code, docs, tokens, screenshots, analytics, or stakeholder symptoms. The audit must be evidence-led, not taste-led.
Evidence Inventory
Label each surface as Reviewed, Partial, Not Provided, or Not Applicable before scoring:
| Area | Evidence |
|---|---|
| Strategy | purpose, scope, roadmap, ownership, funding |
| Foundations | color, type, spacing, motion, radius, elevation |
| Tokens | primitive, semantic, component, modes, transforms |
| Components | anatomy, variants, states, APIs, accessibility, tests |
| Patterns | forms, errors, empty states, navigation, journeys |
| Figma | variables, libraries, modes, publishing, analytics |
| Code | packages, imports, theming, SSR, versioning |
| Docs | component pages, examples, changelog, migration guides |
| QA | visual, interaction, accessibility, token, theme gates |
| Governance | intake, ownership, lifecycle, contribution, deprecation |
| Adoption | onboarding, support, champions, migration help |
| Measurement | usage, runtime coverage, docs analytics, support load |
Score Domains
Score relevant domains from 0 to 4:
| Score | Meaning |
|---|---|
| 0 | Absent or unmanaged |
| 1 | Ad hoc, inconsistent, or local-team only |
| 2 | Defined but incomplete, weakly adopted, or manually maintained |
| 3 | Operational with clear ownership |
| 4 | Measured, governed, accessible, scalable, and improved |
Do not average scores into a single truth. Use scores to reveal dependencies.
Findings
Every individual finding under Critical, High, Medium, and Low must include all six fields:
- Evidence
- Why it matters
- Affected surfaces
- Recommended fix
- Owner or function
- Sequencing dependency
Before final output, scan every finding and add any missing field with a specific value or labeled evidence gap. Do not replace findings with summary tables unless each row contains all six fields.
Roadmap
Group remediation into Stabilize, Standardize, and Scale. Each roadmap
item needs expected outcome and ordering rationale.