Design Audit Method

The shared method behind OnRamp's two design-audit skills. Both reference this page rather than restating it:

• /design-handoff-eval — audits freshly generated handoff output for drift from the design system (static, runs right after /design-handoff-build).
• /design-critique — critiques an established / rendered org-admin page's design quality across seven dimensions.

They differ in subject and altitude, but share the evidence discipline, the forbidden-pattern sweep, and the report conventions below. The design-system prohibitions themselves live in Forbidden Patterns; the compositional standard lives in UI Conventions.

Evidence rule

Every count, ratio, contrast value, and "none found" claim in any section of an audit report MUST cite a line of output from a command run in that report's mechanical-evidence pass. If you did not run the command or probe, you may not state the result. Do not estimate from reading code. No scoring from impression.

This exists because an LLM self-audit overstates compliance — the original handoff audit reported "no custom components" when 16 existed, because it read a few files instead of counting. Each skill opens with a Section 0 mechanical evidence block (run first, paste raw output); every later claim traces to a line in it. What Section 0 contains is skill-specific (a static find/grep inventory for handoff-eval; rendered captures + computed probes for critique) — the rule that everything cites it is shared.

Forbidden-pattern sweep

For each **Pattern:** regex in Forbidden Patterns, run grep -rnE '<regex>' <target> and paste the output. Source the regexes from that canonical doc — never retype them here or in a skill. 0 matches is a valid and required per-pattern result, not an omission.

Report conventions

• Evidence-first. Per the evidence rule above — if a number isn't backed by pasted command output, it doesn't go in the report.
• Direct, no hedging. Findings are facts; recommendations are concise and actionable (a concrete fix, not "improve hierarchy").
• File paths in backticks; line numbers prefixed L (e.g. Foo.vue:L42). Snippets capped at ~80 chars.
• Severity tiers: 🔴 critical · 🟠 medium · 🟡 polish. (Where each skill applies them — flat lists vs. a ranked table — is the skill's own call.)
• Effort tiers: LOW single-file mechanical · MED single-component restructure · HIGH cross-cutting refactor.