Sprint Audit Prompt Pack

What This Is

Five prompts that run a complete design system audit. Use them every sprint to catch drift before it compounds. Each prompt is self-contained and produces a structured report.

How to Use

1. Open Claude Code in your design system project
2. Run each prompt in order (or pick the ones relevant to your sprint)
3. Review the output, create tickets for issues found
4. Track scores over time to measure system health

Run time: ~30 minutes for all 5. Each prompt takes 5-7 minutes.

---

Prompt 1: Naming Audit

Audit the naming conventions across this design system project.

Check:
1. Token naming: do all tokens follow the pattern {category}.{property}.{intent}.{modifier?}?
2. Component naming: are all components PascalCase?
3. File naming: are all files kebab-case?
4. Consistency: is the same separator used everywhere (dots for tokens, hyphens for files)?

For each violation found, report:
- File path and line number
- Current name
- Suggested fix
- Severity (error: breaks convention, warning: inconsistent, info: could be better)

Output as a markdown table sorted by severity.
At the end, give a naming score out of 100.

What it catches: Mixed casing, wrong separators, abbreviation inconsistencies, naming convention violations.

---

Prompt 2: Token Coverage Audit

Audit token usage across all components in this project.

Check:
1. Raw hex values: find any hardcoded colors (#hex, rgb, hsl) not using tokens
2. Hardcoded spacing: find any px/rem values for margin, padding, gap that don't use spacing tokens
3. Hardcoded typography: find font-size, font-weight, line-height values not using type tokens
4. Primitive usage: find any primitive tokens (e.g., blue-500, gray-100) used directly in components instead of semantic tokens
5. Unused tokens: find tokens defined but never referenced in any component

For each issue, report:
- File path and line number
- The hardcoded value found
- Suggested token replacement (if one exists)
- If no matching token exists, flag as "missing token"

Output as a markdown table grouped by issue type.
At the end, calculate:
- Token coverage percentage (components using tokens / total components)
- Number of hardcoded values found
- Number of unused tokens

What it catches: Hardcoded values, primitive token usage in components, unused tokens, gaps in your token coverage.

---

Prompt 3: Accessibility Audit

Audit accessibility across all components in this project.

Check:
1. Color contrast: verify all text/background combinations meet WCAG AA (4.5:1 for normal text, 3:1 for large text and UI components)
2. Focus indicators: verify all interactive elements have visible focus styles
3. ARIA attributes: check for missing or incorrect role, aria-label, aria-describedby, aria-live
4. Keyboard navigation: verify all interactive elements are reachable via Tab and operable via Enter/Space
5. Form labels: verify all inputs have associated visible labels
6. Touch targets: verify interactive elements are at least 44x44px
7. Alt text: verify all images have appropriate alt text

For each issue, report:
- Component name
- Issue description
- WCAG criterion violated
- Severity (A: critical, AA: important, AAA: enhancement)
- Suggested fix

Output as a markdown table sorted by severity.
At the end, give an accessibility score out of 100 and list the top 3 priorities to fix.

What it catches: Contrast failures, missing ARIA, keyboard traps, unlabeled inputs, small touch targets.

---

Prompt 4: Component Health Audit

Audit the health of all components in this design system.

For each component, check:
1. Documentation: does it have a description? Usage guidelines? Props documented?
2. Variants: are all expected variants present (default, hover, active, disabled, focus, error)?
3. Token usage: does it use semantic tokens (not primitives or hardcoded values)?
4. Accessibility: does it have ARIA attributes, keyboard support, focus management?
5. Testing: does it have unit tests? Storybook stories?
6. Consistency: does it follow the same patterns as other components?

Score each component on these 6 dimensions (0-5 each, max 30).

Output:
1. A table of all components with their scores per dimension
2. Overall component health score (average across all components)
3. Top 5 healthiest components (what makes them good)
4. Top 5 components needing attention (what specifically to fix)
5. Patterns: common issues across multiple components

What it catches: Undocumented components, missing states, inconsistent patterns, test gaps.

---

Prompt 5: Drift Detection

Detect drift between the design system source of truth and its implementations.

Check:
1. Token value drift: do token values in code match the token definitions in the tokens/ directory?
2. Component drift: are there components that have been modified outside the design system pattern?
3. Detached instances: are there copies of components that have been disconnected from the source?
4. Stale documentation: is the documentation current with the actual component implementation?
5. Dependency drift: are there outdated or unused dependencies related to the design system?

For each drift detected, report:
- What drifted (file, component, token)
- Expected value (from source of truth)
- Actual value (from implementation)
- When it likely drifted (git blame if available)
- Impact (how many files/components affected)
- Suggested fix

Output as a markdown table sorted by impact.
At the end, give a drift score out of 100 (100 = no drift, 0 = complete divergence).

What it catches: Token values that changed in code but not in the source, modified components, stale docs, dependency issues.

---

Running All 5

Run them in this order for the most useful results:

1. Naming (establishes baseline quality)
2. Token Coverage (most common issues)
3. Accessibility (highest impact fixes)
4. Component Health (comprehensive per-component view)
5. Drift (catches things that changed since last audit)

Tracking Over Time

Keep a simple log after each sprint:

Sprint	Naming	Tokens	A11y	Health	Drift	Overall
Sprint 1	/100	/100	/100	/30 avg	/100
Sprint 2	/100	/100	/100	/30 avg	/100