Skill: run a site coherence pass
Use when a whole website, not one screen, has to read as one site: after several people or agents built pages in parallel, before a launch, or when the owner says the site does not feel coherent. It runs the Site coherence pass method with two tools: a consistency audit and an attention heatmap renderer. For one screen, use the Design review playbook instead.
Inputs
The site at a URL you can load in a headless browser, with a signed-in editor state if drafts or account pages matter.
The owner's standing design rules, and the design system as it is in code (tokens, card anatomy, heading and button rules).
The goal journey, the primary reader, what exists, and what content the author still owes.
Who decides what: brand, money, legal, names and production content writes stay with the owner.
Steps
Read first: Principles (from "One focal path per screen" onward), the method, and the owner's rules for the site.
Write the shared brief as the method's "The shared brief" section lays out: hard limits, how to see the site (visitor, editor and draft views; 390 by 844 and 1440 by 900 widths, the two the capture set holds; screenshots looked at), the standing rules, the finding format, the remove-or-merge list and what works. Add one owner example of the kind of problem to catch when you have one.
Run panel 1: three or four read-only lens agents in parallel (a persona on real errands, a designer who measures, an editor with an old-to-new sentence table, a returning member or learner). Each delivers findings as messages in parts of about 5,000 characters; save them into one findings file per lens.
Merge into one plan: findings cited by lens and number, build batches split by file area, a numbered list of owner calls and a list of content the author owes.
Take owner calls in batches: mockups on one page with the team's pick, numbered yes or no questions with a pick, and all new wording as one old-to-new table. Before any draft is published, compare it with the live version, because a publish carries the draft's other pending edits too.
After the build, run the consistency audit on every page at a phone and a desktop width, in the visitor and the draft view.
Run panel 2: the same lenses re-walk and mark each panel 1 finding fixed, partly fixed or still broken; the auditor turns the audit into findings and a proposal for one presentation per kind.
Check focal paths on the key first views with attention heatmaps when the order of attention is in question, comparing variations of the same content.
For one first screen that feels "good and overwhelming at once", run the method's fit pass: three lenses in parallel (hierarchy and weight, a first visitor on a phone, editorial references), measured on the live page with
getBoundingClientRect,getComputedStyleand pixel counts; every change tried as injected CSS with before and after at 1440 and 390; one review page with numbered calls and a pick; then a grid build with browser tests pinning the measured numbers.Fix, then re-run the audit and record the before and after numbers next to each finding.
Write back: reusable lessons to this organization (Principles, the method's Runs, the Research log); product decisions to the product's own documents.
Tool: consistency audit
A reusable toolkit is being built but is not yet published (see the end of this Skill). Until it is published, this is what it does, so anyone can rebuild it in a headless browser script.
Inputs: a base URL; a list of paths; widths (default 1440 and 390); views (visitor and draft, switched through the site's own preview controls in a signed-in browser state); the site's tokens to check against (heading sizes per width, allowed text sizes, allowed text colours).
For each page, width and view:
load the page and scroll to the end so lazy pictures load, then scroll back;
headings: tag, text, font family, size, weight, position, and whether the heading sits inside a link;
items: every link in the main content that holds a picture, with the section it belongs to (the nearest heading above it), its layout (a card when the title sits under the picture, a row when it sits beside it), the picture's normalised source (resize parameters stripped, a video thumbnail reduced to its video id), natural size, drawn size and ratio, object fit and corner radius, the title's font and offset, and the font of each other text line;
gaps: the space above each section heading, measured from the last visible content before it;
end space: from the last visible content to the footer;
tally: every font size and weight, text colour, background, picture corner radius and button variant (height, border, fill, font, radius), and every underlined link outside prose;
a full-page screenshot and one cropped screenshot per section that holds items.
Output: one JSON file per width and view, plus the screenshots.
Analysis step: reads the JSON and prints, per page and section:
each item's signature (layout, picture size and ratio, title font, text lines), so one kind drawn two ways shows up as two signatures;
REPEAT when one picture source appears twice in a section;
PADDED when a video thumbnail is drawn in a slot that is not upright (width more than 0.7 of the height), because a video service may pad an upright video's landscape thumbnail with side bars (see Principles, Pictures: never twice, never through a face, video frames in their own ratio);
MISALIGNED when titles in one row start at different offsets;
BARE when an item has a title and nothing else;
headings off their token size or face; text sizes and colours off the scale; underlined links outside prose; the button variants; and the end space per page.
Limits: it measures computed styles, not perceived quality. It cannot see faces: it flags padded video frames, one known cause of a crop through a person, and leaves the section crops for a person or a vision model to check.
Tool: attention heatmap renderer
Part of the same toolkit, also not yet published. What it does:
Inputs: a screenshot (PNG) and a fixations file: a list of up to three fixations, each with a rank, a box as left, top, right and bottom in percent of the screenshot, and a reason; or several runs of such lists, which are averaged.
Where the fixations come from: a vision model looks at the screenshot (with percent rulers in a margin outside the image) and names a first-time visitor's first three fixations in the first two seconds. The prompt names no design principle. Run it three times with no shared context.
What it draws: one Gaussian per box (spread a quarter of the box's width and height, at least 1.5 percent of the side), weighted 1, 0.8 and 0.6 for fixations 1 to 3; each run normalised, then averaged; a cool-to-warm colour ramp with low values transparent so the design shows through; dashed outlines and the numbers 1 to 3 at the first run's boxes; and the label "modelled attention, not observed" on the image.
Output: the screenshot with the overlay, as a PNG.
Limits: validated once, on 30 desktop web pages from the UEyes eye-tracking dataset (validation in the Site coherence pass): better than centre bias, worse than a plain average of where people look on web pages. A critique aid for comparing compositions, never user evidence.
Verification
Every finding names its page, view and width and has a screenshot.
Every panel 1 finding has a status from panel 2.
The audit's before and after numbers are recorded for each fixed finding.
Every heatmap carries the "modelled attention, not observed" label.
Every new sentence on the site went through the owner's wording table.
Limits
Lens panels and heatmaps model people; they do not observe them. Label their findings as critique (Principle 14). The method has run several times between 13 and 16 October 2026, all on one site (Runs in the Site coherence pass); no second site has tried it yet.
The toolkit
The deterministic part of this pass is being built as a reusable toolkit. It is not published as of 29 October 2026, so build the audit and the renderer from the two tool sections above. The toolkit covers screenshots at several widths and views, the consistency inventory and its flags, overflow and fold checks, accessibility checks with axe-core (https://github.com/dequelabs/axe-core, read 2026-10-29), link checks and a heatmap renderer for given fixations, written into one HTML report. Each site has a small config (base URL, pages, widths, views, token source, primary action). Run it before and after a fix batch and put the numbers in the findings. Model steps (fixations, lens reviews) still run through the agent doing the pass; a later version may run them without an agent.