Skip to content
Dave Klein

Design analysis

Download the skill2 KB

Turns “look at this site” into measured captures and a short adopt-or-skip rubric, then builds lab experiments from your real content. Design analysis is one of the Claude Code skills I wrote for building this site, with the site-specific values turned into placeholders and examples so it works on any project. The skill is the SKILL.md below, exactly as it ships in the zip.

Install

unzip design-analysis.zip -d ~/.claude/skills

That installs it for every project. For one project, unzip into that project’s .claude/skills/ instead. Either way, Claude Code reads the folder on its next session and applies the skill when a request matches its description:

Analyze a reference site against your own design system. Capture the reference with real measurements, compare it to the system you actually have, produce a short scored rubric of adopt, adapt, and skip verdicts, and build gated lab experiments that demonstrate the winners with real content. Invoke whenever someone shares a URL to learn from ("look at <url>", "compare <site> to mine", "what can we steal from <site>").

Inside the zip

  • —design-analysis/SKILL.md · 4 KB

The skill

Turn “look at this site” into four things, in order: a faithful capture, a comparison grounded in your own code, a few opinionated recommendations, and working experiments.

1. Capture the reference

  • Fetch the page and pull real values, not impressions: the type scale and families, line lengths, spacing rhythm, how many colours are in play, the border and shadow vocabulary, motion (durations and easings), density.
  • For anything computed (rendered sizes, easing curves, scroll behaviour), use a browser with DevTools access: navigate, then evaluate_script with getComputedStyle and getBoundingClientRect. Measure first. A screenshot confirms a result; it does not find one.
  • Note features as well as aesthetics: the navigation model, list and detail patterns, footers, how provenance and metadata are shown, easter eggs, personal-site tropes done well.

2. Compare against your site, not in the abstract

Ground every comparison in the real system and cite file:line for your side. Before the first comparison, locate these in the codebase and keep the paths in the report:

  • Tokens and recipes: the theme file (a @theme block or a tokens file) and the named recipe classes for titles, labels, links, and grid columns.
  • The shell: the fixed header and its height, the shared page wrapper, the grid, the reading column.
  • Type: which families and weights are loaded, fluid sizes, tracking rules, text-wrap settings, hanging punctuation.
  • Motion: the springs and easings already in use, their durations, and the school they follow (fast, subtle, interruptible is a good one).
  • Surfaces: the accent colour, whether floating surfaces use shadows or borders, how light and dark themes are wired.

3. Recommendations: a rubric, not a listicle

Produce one table: pattern, what they do, what we do, verdict (adopt, adapt, or skip), and why. Keep it to seven rows or fewer. Taste over volume.

Standing rules pre-decide some verdicts. Read the project’s instructions file for its own list and apply it. Common ones: extend the design system rather than add one-off overrides; new pages use the shared page shell; images go through the framework’s image component; a performance floor (100 Lighthouse, or whatever the project states) is hard, so a pattern that costs performance is a skip no matter how pretty.

4. Experiments in a gated lab

Build each adopt or adapt verdict as a route under a lab path (one route per direction, or one route with a variant toggle), using real site content, an actual post, actual photos, never placeholder text.

  • The lab must be gated from production (a middleware or proxy that rewrites lab routes to 404 when the deployment is production). Dev and preview deployments show it. Never link lab routes from production UI.
  • Scrub third-party names from shipped code, comments, and copy. The analysis document can credit its sources; the code cannot.
  • Register the page in the lab index with its tier and a one-line intent, matching the existing entries.
  • Lab pages still follow the system (the shell is optional there, tokens and recipes are not), so a winning experiment ports cleanly.

5. Deliverable

The final response is the rubric table, a link to each lab route, and a port plan per winner: which real component or page changes, in what order. After porting a winner into production components, run a design QA pass before calling it done.