How the score works.
The Rams Design Score is a single number from 0 to 100 that summarizes the design quality of a codebase's UI layer. It's applied the same way every time, against the same ruleset, by the same reviewer.
What it measures.
It reads code the way a senior designer reviewing a pull request would. It does not run the app, take screenshots, or evaluate visual aesthetics.
Rams reviews the UI code itself: the .tsx, .jsx, .vue, .svelte, SwiftUI .swift, and styling files that produce the rendered interface. Issues are evaluated against 308 rules across 9 design categories, each catching a specific failure mode.
The 9 categories.
Every rule lives in one of these. Each specialist reviews the diff with its own rules, the way a real design team splits the work.
Semantic HTML, keyboard navigation, screen-reader compatibility, focus management, ARIA correctness, color contrast on text. Things WCAG 2.2 AA cares about and that real users with disabilities run into.
Hardcoded hex values that bypass design tokens, contrast ratios, semantic color usage, hover and focus states.
Heading hierarchy correctness, font scale adherence, line height, font weight, text truncation patterns.
Whether layout values come from a scale (4/8/16) or are arbitrary one-offs. Padding and margin consistency. Gap usage.
Component composition, prop API design, primitive reuse, design-system token leaks, in-line style overrides.
Loading states, empty states, error handling, destructive action confirmations, form patterns, scroll behavior.
Animation duration and easing, prefers-reduced-motion support, infinite loops, layout shifts caused by animations.
Patterns specific to AI-generated UI code: arbitrary radius values, magic numbers, overly defensive null checks, unused props, copy-paste duplication.
SwiftUI and Apple-platform conformance: SF Symbols over emoji and raster icons, Dynamic Type, safe areas, semantic system colors and Dark Mode, VoiceOver traits, Reduce Motion, right-to-left layout.
How issues are weighted.
Each issue carries a severity. The score deducts points by severity, and criticals cap the score — one at 59, two at 49, three or more at 39 — so a 60 or above always means zero critical issues. The number answers one question: is this ready to merge?
Critical: breaks core functionality, blocks accessibility, ships visible bugs. Heaviest deduction.
Serious: degrades quality, leaks design-system intent, will cause user-facing regressions. Moderate deduction.
Moderate: minor polish or convention issue. Light deduction. (Excluded from the public score view to focus attention.)
Score bands.
Brighter is safer to ship. A high score means the UI clears the bar with no critical issues left standing.
What the score doesn't measure.
The score has a boundary on purpose. These belong to other tools, and reading them into a design number would only blur it.
How public scoring samples a repo.
The homepage widget scores a representative slice. For continuous review on every pull request, the GitHub App reads exactly the files that changed.
When you score a public repo via the homepage widget, Rams pulls up to 30 UI files prioritized by location (app/, pages/, components/) and reviews them as a representative sample. A score of 100 is reserved for a repo small enough to read end to end. Anything larger is sampled, and sampling caps the score at 98. The number never claims more coverage than the review had. For continuous review on every pull request, install the GitHub App. It reviews exactly the files that changed.
Methodology stability.
The rubric is intentionally stable, and scores are versioned: every score names the engine that produced it. We don't loosen rules to flatter scores. When the engine changes meaningfully, we rescore the public set on the new version and keep the history in the open — a score never moves silently. Every change is logged below.
Changelog.
When rules are added or weights revised, it lands here. The counts and areas are public. The rule text stays in the engine.
The critical cap is now a ladder. One confirmed critical still caps a score at 59 — that sentence has not moved. But half the public catalog sat at exactly 59, where a repo with one blocker and a repo with five read identically. Now two criticals cap at 49 and three or more at 39, so the number ranks what it used to flatten: a score in the 50s means one blocker, the 40s mean two, the 30s mean a pile-up. Sixty and above still means zero criticals, always. Verified on the fixture bench against the previous engine — identical findings, only the cap arithmetic moved — and the public catalog was re-capped in place.
Thirty-three rules across eight categories, drawn from a study of the craft the design-engineering community now ships as agent skills — and the study’s loudest finding was convergence: most of what those artifacts check, the engine already checked. The new rules cover the gaps: height reveals that animate real size, one entrance per container, staggers that follow hierarchy, per-frame values kept out of React state, inputs whose decorations are actually clickable, Enter that submits, validation that waits for you to finish, actions that commit on release, destructive buttons kept at a distance, hidden UI that leaves the tab order, icons with one meaning and the right optical weight, components that pass refs and props through, themes that flip tokens instead of components, and canvas effects that degrade to real content. Four existing rules sharpened, including a deliberate stance: ease-in stays banned everywhere except exits — departing elements accelerating away is physics. Touch targets raised to Apple’s 44px floor. Verified on the fixture bench: zero new findings on clean work.258291 rules
The engine now measures before it judges: contrast ratios and design-token usage are computed from the code itself and cited exactly, never estimated. Every finding is located first, then checked against the code that proves it before it is written, so a claim the code does not support is dropped instead of published. Accessibility lockouts always take priority over style notes. Reviews run about 20% faster. Scores moved when we rescored the catalog on this version, and the movement is worth explaining: most repos did not change at all, and where a score moved it was almost always the critical cap. Criticals that could not be evidenced in quoted code fell away, so repos capped at 59 by a finding that did not hold up rose. The engine also caught criticals the previous version missed, including controls unreachable by keyboard and infinite animation with no reduced-motion guard, so some repos dropped to 59 for the first time. Both directions come from the same change.
Largest batch yet, and a ninth category: Native, for SwiftUI and Apple-platform work. New rule families for agent-built UI and cross-app coherence. Review restraint recut: zero findings on clean work is a valid verdict, and every critical is re-verified before it can cap a score.194258 rules
7 rules added from production reviews. Reviewer precision improved: the engine reads a codebase’s own design system before judging it.167174 rules
1 craft rule added, from a pattern seen repeatedly in the wild.166167 rules
47 rules added across five categories, and 25 existing rules sharpened with tighter detection.119166 rules
Scoring: any critical issue now caps the score at 59, so a score of 60 or above always means zero critical issues.
Re-reviews now verify fixes: resolved findings are named and the score recovers. 10 rules added, 5 sharpened.109119 rules
Initial public methodology: 109 rules across 8 categories, severity-weighted scoring.
Score your own repo with Rams.
Free on public repos. Rams reviews every pull request against these 308 rules and posts inline fixes.
Frameworks