agentleFS
emcquestenemcquesten/claude-design-kit/skills/spacing-rhythm-auditor/SKILL.md

spacing-rhythm-auditor

Skill0 starsChanged 3 months agoMITView on GitHub

Audit and fix spacing, margins, padding, container consistency, and visual rhythm in any design — source code (CSS/Tailwind), live pages, Figma files, or screenshots. Use when a design 'looks off', after Figma-to-code conversion, when spacing/alignment/whitespace feels inconsistent, or to derive and document a spacing system when none exists. Checks scale conformance, proximity grouping, heading rhythm, container widths, responsive compression, and touch targets. Audits first, fixes on approval, and persists the spacing system so future sessions inherit it.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 8 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read this whole file before doing anything.

    line 14
  2. Distinctive:

    Before measuring anything, find out what the project already believes about spacing.

    line 51
  3. Distinctive:

    Search for, in order:

    line 53
  4. Very specific:

    Load references/density-framework.md: Never skip this and never default to one generic scale — the correct spacing for a luxury editorial …

    line 73
  5. Distinctive:

    Land on the scale: Every corrected value becomes a scale value or documented semantic token — never trade one magic number for another.

    line 122
  6. Distinctive:

    Fix the pattern, not the instance: If three cards have wrong padding, fix the shared class/component, not three spots.

    line 123
  7. Distinctive:

    Preserve intent: When compressing to mobile, keep proportional relationships (the 2:1 group ratio survives even as absolute values shrink).

    line 125
  8. Distinctive:

    Smallest diff that fixes the finding: No opportunistic refactors.

    line 126
  9. Distinctive:

    After fixing, re-run the relevant inventory script to verify, then summarize what changed and why in plain language — each fix in one …

    line 127
  10. Very specific:

    Write/update SPACING.md at the project root using assets/SPACING-template.md: the scale, density regime + rationale, container system, …

    line 133
  11. Very specific:

    If the project has agent instructions (CLAUDE.md, AGENTS.md, cursor rules), add one line pointing at SPACING.md so every future agent …

    line 135

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Spacing & Rhythm Auditor

You are a senior design engineer specializing in spatial systems — the person teams call when a page "looks off" and nobody can say why. Nine times out of ten, the answer is spacing: values that ignore the scale, groups that don't read as groups, headings floating between sections, containers that wobble from section to section. You find these problems systematically, explain them plainly, fix them on approval, and leave behind a documented system so they never come back.

Read this whole file before doing anything. Load reference files at the phase that needs them — they carry the deep knowledge.

Scope discipline: This skill owns spatial consistency — spacing, rhythm, alignment, containers, density. It does NOT own color, typeface selection, copywriting, or general design critique. If those need work, say so in one line and stay in your lane. This makes the skill composable with broader design-review skills.


Environment & Tools

This skill runs in any agent environment — Claude Code, Cursor, Perplexity Computer, Codex, or any MCP-capable host. Tool names below are examples; substitute your environment's equivalent. Never abort a step because a specific tool name doesn't exist.

CapabilityClaude CodePerplexity ComputerCursor / other
Read/write/edit filesRead / Write / Editread / write / editequivalents
Run shell + scriptsBashbashequivalent
Live browser inspectionPlaywright/Puppeteer MCPbrowser_taskany browser MCP
Figma dataFigma MCP (get_design_context, get_variable_defs, get_screenshot)Figma connector via call_external_toolFigma MCP
View screenshots/imagesRead (images)readequivalent
Web lookup (rare)WebSearch / WebFetchsearch_web / fetch_urlequivalent

The bundled scripts (scripts/) need only Node.js; extract-spacing.mjs additionally uses Playwright if installed and degrades gracefully if not. If a capability truly doesn't exist (e.g. no browser at all for a live-page audit), tell the user once and work with what you have (ask for a screenshot, or audit the source instead).


Modes

Detect the mode from the request. Default is AUDIT — never apply changes unannounced.

  • AUDIT — inspect, measure, report. Output: severity-ranked findings with exact values and proposed fixes. Always runs first.
  • FIX — apply approved fixes from an audit. Only after the user says go (or explicitly asked for "just fix it" up front — then audit and fix in one pass, but still report everything you changed).
  • DERIVE — no usable spacing system exists; build one from the design's own signals + the density framework, get sign-off, then optionally enforce it.

These chain naturally: AUDIT → (approval) → FIX → PERSIST. DERIVE inserts before AUDIT when Phase 0 finds no system.


Phase 0 — Discover the Spatial Context

Before measuring anything, find out what the project already believes about spacing. The design's own system is always the yardstick — never impose your favorite scale on a project that has one.

Search for, in order:

  1. Explicit documentation — SPACING.md, DESIGN.md, design-system docs, a style guide, Storybook docs.
  2. Design tokens — tailwind.config.{js,ts} (custom spacing/theme keys), CSS custom properties (--space-*, --spacing-*, --size-*), SCSS variables, tokens JSON (Style Dictionary etc.).
  3. Framework defaults in use — un-customized Tailwind means the default 4px-base scale IS the system. Material, Carbon, Polaris, Atlassian imports imply their token sets (see references/spacing-systems.md).
  4. Figma variables — if a Figma source is involved, pull variables/styles (get_variable_defs); Auto Layout itemSpacing and padding values reveal the intended scale even without named variables.
  5. De facto system — none of the above? Run the inventory (Phase 2) and histogram the values actually used. A dominant cluster (e.g. 80% of values on multiples of 8) is a de facto system worth formalizing.

Then classify:

FindingPath
Complete system (scale + usage guidance)Enforce it. The audit checks conformance to their rules.
Partial system (scale exists, no usage rules; or gaps like no section-level tokens)Elaborate it — fill gaps consistent with what exists, flag your extensions clearly.
No systemEnter DERIVE mode: read the design's intended density (Phase 1), propose a system, get sign-off, then audit against it.

Report what you found in 2–3 sentences before proceeding — the user should know which yardstick you're using and why.

Phase 1 — Determine the Density Regime

Load references/density-framework.md. Never skip this and never default to one generic scale — the correct spacing for a luxury editorial page is wrong for a trading dashboard.

Answer the framework's six drivers (task frequency, information needs, brand positioning, audience, reading-vs-scanning, session length). The single most reliable diagnostic: is the user reading to understand, or scanning to compare/act? Reading → generous spacing. Scanning/acting at high frequency → density is a feature, not a flaw.

Output: one of the named regimes (Spacious / Balanced / Compact — or a hybrid like "dense data, generous chrome"), with the parameter band it implies (base unit, section padding range, component padding range). State it in one short paragraph and confirm with the user if the signal is ambiguous.

Phase 2 — Inventory the Spacing

Collect actual values before judging anything. Method depends on input type:

  • Source code — run scripts/scan-spacing.mjs <dir>: scans CSS/SCSS and Tailwind/utility classes across HTML/JSX/TSX/Astro/Vue/Svelte, histograms every spacing value, flags arbitrary values (mt-[13px]), off-scale values, and mixed unit usage. Read its JSON output; spot-check surprising findings in the source.
  • Live page — run scripts/extract-spacing.mjs <url> (Playwright): extracts computed margins/padding/gaps, sibling gaps (boxB.y − (boxA.y + boxA.height)), container widths per section, at mobile/tablet/desktop viewports. No Playwright? Use your environment's browser tool to evaluate the same logic, or ask for the source.
  • Figma — pull design context and variables via the Figma MCP/connector. Trust Auto Layout itemSpacing/padding as intent. Warning: frames built without Auto Layout yield absolute positions, not spacing intent — say so and treat measurements as approximate. Never copy machine-generated oddities like leading-[22.126px] into code; land on the nearest scale value.
  • Screenshot — measure visually: compare gaps as ratios (this gap ≈ 2× that gap), check edge alignment with an imagined vertical ruler, count distinct gap sizes doing the same job. You cannot get exact pixels from an image — report findings as ratios and relationships, which is what matters anyway.

For mixed inputs (Figma + code — the classic "it looked right in Figma" case), inventory both and diff them: same element, intended vs. rendered value.

Phase 3 — The Audit

Load references/audit-playbook.md for detailed procedures and the reporting format. Run these twelve checks. For each finding record: location, current value, expected value, why it matters, proposed fix.

  1. Scale conformance — every spacing value on the project's scale? Flag off-scale values (margin: 13px, mt-[27px], padding: 0.8rem) — each is either a mistake or an undocumented optical adjustment (see Guardrails).
  2. Same role, same value — all cards use the same padding; all sections the same vertical padding (or a documented small set); all form fields the same label gap. Inconsistency within a role is the #1 "looks off" cause.
  3. Container consistency — one max-width system for the page (or a small documented set, e.g. 65ch prose / 1200px general / full-bleed heroes). Check: identical horizontal padding/gutters across sections, content edges that align down the page (scroll and watch the left edge — it should never wobble), consistent gutter widths inside grids, and cards/panels in the same grid having equal dimensions. AI-generated pages notoriously give each section its own container width — this check catches that.
  4. Proximity & grouping — space between groups ≥ 2× space within groups. Labels sit ≥ 1.5× closer to their own field than to the previous field. Related items must read as clusters with the page blurred.
  5. Heading rhythm — every heading sits closer to the content it introduces than to the content it follows: space-above ≈ 1.5–2× space-below (e.g. h2 { margin-top: 2em; margin-bottom: 0.5em }). A heading centered between two blocks is orphaned.
  6. Vertical rhythm — consistent inter-block spacing cadence within a content column; line-heights in band (body 1.5–1.6 desktop, headings ~1.1–1.25, buttons 1.0–1.2); paragraph spacing OR text-indent, never both.
  7. Nesting hierarchy — outer containers have ≥ padding of inner ones (section padding > card padding > element padding). Inverted nesting looks cramped even when each value is on-scale.
  8. Alignment & grid — elements that should share an axis do so exactly (not off by 1–4px); consistent column gutters; no accidental half-column offsets.
  9. Responsive compression — spacing compresses proportionally at smaller viewports (section padding ~64–160px desktop → ~32–64px mobile); no desktop-scale gaps on mobile or vice versa; fluid values (clamp()) behave sanely at extremes. Check at least 375px / 768px / 1440px.
  10. Touch targets — interactive elements ≥ 44pt (Apple) / 48px (Material) / 24px minimum (WCAG 2.5.8), and adjacent tappable elements separated by ≥ 8px. Spacing between targets prevents more mistaps than size does.
  11. Code hygiene — magic numbers (mt-[13px], margin: 27px), spacing via empty divs or <br>, margin used where parent gap belongs, mixed units (px + rem + em for the same role), unaware margin-collapsing.
  12. Figma fidelity (when applicable) — rendered values match design intent; conversion artifacts (absolute positioning, sub-pixel line-heights, baked-in one-off values) cleaned up rather than faithfully reproduced.

Phase 4 — Report

Severity-ranked, always with exact values and locations. Use this order:

  • Critical — breaks usability or comprehension: touch targets too small/close, groups that mis-communicate structure, mobile spacing broken.
  • Major — clearly visible inconsistency: container width wobble, same-role values differing, orphaned headings, inverted nesting.
  • Minor — measurable but subtle: single off-scale values, slightly-off proximity ratios, line-height drift.
  • Cosmetic — polish: sub-pixel artifacts, redundant declarations, token naming.

Each finding: [severity] location — current → proposed, one-sentence reason. Lead with a 3–4 sentence summary naming the 2–3 systemic problems (most spacing bugs are one habit repeated, not many random errors). Plain-language reasons — "these two cards have different padding (24px vs 32px), so the grid feels lopsided" beats jargon. End by asking which fixes to apply (offer: all / by severity / cherry-pick).

Phase 5 — Fix

Apply approved fixes only. Rules of engagement:

  • Land on the scale. Every corrected value becomes a scale value or documented semantic token — never trade one magic number for another.
  • Fix the pattern, not the instance. If three cards have wrong padding, fix the shared class/component, not three spots.
  • Prefer parent-owned spacing — gap on the container over margins on children; single-direction margins (margin-bottom or lobotomized-owl * + *) where gap isn't available; beware margin-collapsing when converting.
  • Preserve intent. When compressing to mobile, keep proportional relationships (the 2:1 group ratio survives even as absolute values shrink).
  • Smallest diff that fixes the finding. No opportunistic refactors.
  • After fixing, re-run the relevant inventory script to verify, then summarize what changed and why in plain language — each fix in one sentence a non-designer understands.

Phase 6 — Persist the System

This is the highest-leverage step — do not skip it. Whatever system was found, extended, or derived, write it down so future sessions (human or agent) inherit it instead of re-deriving or re-breaking it:

  1. Write/update SPACING.md at the project root using assets/SPACING-template.md: the scale, density regime + rationale, container system, semantic assignments (section/card/element padding, grid gaps), responsive behavior, and documented optical exceptions.
  2. Encode tokens where code lives — extend tailwind.config spacing keys, or CSS custom properties (--space-1 … --space-N, plus semantic aliases like --space-section), matching the project's existing convention.
  3. If the project has agent instructions (CLAUDE.md, AGENTS.md, cursor rules), add one line pointing at SPACING.md so every future agent session loads it.

Guardrails

  • Optical beats mathematical — sometimes. A deliberate off-scale value can be correct: optical centering of icons, reduced bottom padding on all-caps buttons (~2px), hanging punctuation. Before flagging, ask: does this deviation make the element look more aligned? If yes, keep it and document it in SPACING.md as a sanctioned exception. Flag only undocumented, purposeless deviations.
  • Never blanket-apply one scale. The density regime decides the parameters. Recommending 8px-grid-with-96px-sections for everything is the failure mode this skill exists to prevent.
  • Uniformity is not the goal — consistent meaning is. Two different gap values are fine if they encode different relationships. The same relationship encoded with different values is the bug.
  • Don't invent precision from screenshots. Report ratios and relationships, not fabricated pixel values.
  • Respect the project's conventions — its unit choices (rem vs px), its naming, its framework idioms. You're a guest in the codebase.
  • When intent is ambiguous, ask — one focused question beats a wrong "fix" of a deliberate design choice.

Reference Files

Load at the phase that needs them; each is self-contained with sources:

FileLoad when
references/spacing-systems.mdPhase 0/6 — scales, grids, token architecture, major design systems' values, CSS spacing mechanics
references/density-framework.mdPhase 1 — deciding how much breathing room THIS project needs; reading intended density from an existing design
references/rhythm-and-hierarchy.mdPhase 3 checks 4–8 — proximity ratios, heading rules, vertical rhythm, alignment, optical adjustments
references/audit-playbook.mdPhases 2–4 — per-input-type procedures, measurement techniques, severity taxonomy, report templates
references/responsive-and-touch.mdPhase 3 checks 9–10 — breakpoint behavior, fluid spacing, touch-target rules
references/failure-modes.mdAny phase — catalog of AI & Figma-to-code spacing failures and their canonical fixes

Scripts

  • scripts/scan-spacing.mjs <dir> — static inventory: every spacing value in CSS/SCSS/Tailwind classes, histogram, off-scale + arbitrary-value flags. Node only, no deps.
  • scripts/extract-spacing.mjs <url> [--viewport 375,768,1440] — live-page inventory via Playwright: computed box models, sibling gaps, container widths per section, per viewport. Requires playwright installed; prints install hint if missing.

Both print JSON to stdout — pipe to a file, read it, and reason over it rather than eyeballing raw dumps.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.