Park the design-comparison tooling for a decision

[pbking]

Parked for you to look at later, as discussed — nothing in guides/ references these and .distignore keeps tools/ out of the wp.org build. The pattern-author skill reaches agents through the abilities, which are JSON in and JSON out; whether scripts should travel that way is a separate decision from writing guidance, and this branch exists so the tooling isn't lost while that's open.

What they are

Two scripts for "does what I built match the design I was copying?", written after a four-page rebuild where that got checked by eye at the very end and four transcription errors survived to it: elements.button line-height inherit where the source said 1.1, core's default button padding against 0.9rem/1.6rem, a 24px block gap against 20px, and the layout widths.

compare-design-system.mjs — no browser, nothing to install. Pulls the global-styles-inline-css block out of two pages and diffs it rule by rule. That stylesheet is the design system exactly as the browser sees it, so a difference there is a difference in what was installed rather than in how a pattern used it. All four errors above are in its first screen of output.

Two things make the output usable rather than a wall:

• Values are compared as CSS means them — #17120E and #17120e is not a finding.
• A property one side simply lacks is counted, not listed, and kept separate from a property whose value differs. The first is usually a deliberate difference between two themes (a blank theme strips core's palette); the second is nearly always a mistake. Mixing them buried the mistakes.

Run against the site that prompted this, it reduces two 100KB stylesheets to one finding:

:root
   --wp--style--global--content-size: 46rem   ->   800px
   --wp--style--global--wide-size: 80rem   ->   1200px
   (38 properties the source has and mine does not: --wp--preset--color--black, …)

Which is correct — those widths are genuinely still wrong on that site, because set-layout didn't exist when it was built.

compare-render.mjs — the second pass, once the design system agrees. Loads both pages in Playwright and compares the computed style of every element carrying text, matched on the text itself. That works because when you're reproducing a design the copy is identical by construction, so nothing has to guess which element corresponds to which. Reports per-property differences, then where the two documents drift apart vertically.

If you'd rather they lived somewhere else

The obvious alternatives, in rough order of how much they'd change:

1. Leave them here as developer tooling, undocumented in the skill — the current state.
2. A get-design-system-diff ability that takes a URL and diffs that page's stylesheet against this site's. Server-side PHP, no script shipped; the cost is an outbound fetch to a caller-supplied URL, which is a security question worth its own conversation.
3. A separate repo or gist, if this doesn't belong in the plugin at all.

I'd lean 2 for the design-system half — it's genuinely useful over the wire and needs no browser — and 1 or 3 for the render half, which can't escape needing Chromium.

🤖 Generated with Claude Code

https://claude.ai/code/session_017Fr6uocsyi8N5b5YejYjcs

---

Generated by Claude Code