# Sprint Audit Prompt Pack

5 prompts for a complete design system audit. Run every sprint. ~30 min total.

---

## 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.
```

---

## 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
```

---

## 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.
```

---

## 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
```

---

## 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).
```

---

## Score Tracking

| Sprint | Naming | Tokens | A11y | Health | Drift |
|--------|--------|--------|------|--------|-------|
| Sprint _ | /100 | /100 | /100 | /30 avg | /100 |
| Sprint _ | /100 | /100 | /100 | /30 avg | /100 |
| Sprint _ | /100 | /100 | /100 | /30 avg | /100 |