Designer Frontend Contract
designer-frontend-contract/
Freeze an approved mockup into a reference, port it 1:1 on any stack, and verify every page, state and breakpoint with screenshot diffs before merge.

The tech-agnostic contract between designer and frontend dev, and the gate that mechanically enforces it.
Why use it
- "Matches the design" asserted from a screenshot glance, while a whole page region is missing.
- The build quietly re-styles the mockup, and the drift is only noticed after launch.
- HTTP 200 and a green CI badge say nothing about whether the UI is actually right.
What it does
- Designer side: freeze the approved mockup into a canonical oracle: manifest, baseline renders, a region/element inventory, token parity, a visual acceptance contract.
- Frontend side: port the oracle 1:1 (transcribe, never redesign) and self-gate census → DOM → pixel before handoff.
- Verifier side: independently screenshot every page × access state × pinned breakpoint against the frozen baseline; census FIRST, then pixel diff, then interaction hit-testing.
- Report-only verification: findings route to the dev (drift) or the designer (a legitimate design change).
Benefits
- Ship what was actually designed. Fidelity becomes an enforced gate, not an assumption.
- Catch the missing region the pixel diff would have waved through.
- No more launch-day drift: every page, state and breakpoint is checked before merge.
- Any stack. Dev server, template language and tokens all come from your project config.
Install
Download this skill and copy the designer-frontend-contract folder to .claude/skills/designer-frontend-contract/ in your project, or to ~/.claude/skills/designer-frontend-contract/ to use it in every project. Claude Code finds it on its own; you can also call it with /designer-frontend-contract.
Part of the Web Dev Design Pipeline bundle. To get the whole set as a Claude Code plugin: /plugin marketplace add endorphin-ai/hasbrains-agent-kit, then /plugin install web-dev@hasbrains-agent-kit.
Source: endorphin-ai/hasbrains-agent-kit. License: MIT.
Files (18)
Files
---
id: baseline-and-oracle
title: The oracle + establishing/refreshing a baseline (incl. the design-phase-skipped migration case)
summary: What the design oracle is (frozen renderable mockup = pixel oracle; design-tokens + design-system.md = rule oracle), how to resolve it per page/state via oracle-manifest.json, canvas-export de-framing, and how to ESTABLISH a baseline when none exists or REFRESH one when the design legitimately changed.
tags: [contract/oracle, contract/baseline, contract/migration]
aliases: [oracle, frozen baseline, establish baseline, refresh baseline, no oracle, design phase skipped, migration baseline, oracle manifest]
load_when: Resolving/refreshing the baseline; no oracle exists yet for a page; the design legitimately changed; a design-phase-skipped migration run.
links: [[design-diff]], [[fidelity-checks]], [[designer-handoff]], [[region-census]]
---
# The oracle + establishing/refreshing a baseline
## What the oracle is
Three layers, all owned by the DESIGNER and committed under `docs/design/`:
- **Canonical oracle — ONE frozen, renderable file per page.** Exactly one approved mockup
file is THE oracle for a given route. `docs/design/` accumulates many candidate files per
feature (multiple mockups, canvas exports, state variants) — so resolve the oracle via the
**manifest** (`docs/design/oracle-manifest.json`: route → canonical oracle file +
baseline dir + inventory file, per [[designer-handoff]]). Never guess which of several
files is authoritative — read the manifest. A missing manifest entry is itself a
`[NO-ORACLE]` finding: ask the designer to declare it.
- **Baseline renders — the pixel target.** Static captures of the canonical oracle at the
pinned breakpoints under `docs/design/baseline/<page>-<width>.png`. The build's
screenshots are pixel-diffed against THESE.
- **Rule oracle — the design system.** `docs/design/design-tokens` (mirroring the app's
single declared token source — per `{config.frontend_runtime}`; never assume a
utility-framework config) and `docs/design/design-system.md` — palette, type scale,
spacing grid, radius/shadow, 60/30/10 balance, AVOID list. These catch drift a pixel diff
misses and explain a FAIL.
Also read the per-feature `docs/design/<feature>-design-spec.md` for the **visual
acceptance contract**: the pinned breakpoint widths, the per-breakpoint pixel threshold +
exclusions, and the pointer to the region/element inventory the census ([[region-census]])
runs against.
**Canvas-export oracles.** Some oracle files are design-tool *canvas* exports — the real
page markup wrapped in an absolutely-positioned device frame (a positioned wrapper, a
bordered "screen" div, tool scaffolding attributes). The page CONTENT inside (normal
document flow) IS the oracle; the canvas wrapper is not. When censusing/diffing against a
canvas export, scope to the inner screen element and ignore the frame — or ask the designer
to emit a de-framed render for the baseline PNGs.
## Resolving the oracle per page × state
Each built page maps (via the manifest) to its canonical oracle + the access states it was
designed for. Diff each state against ITS OWN oracle — never diff an entitled render
against the anonymous baseline, or a locked/paywall state against the unlocked mockup.
Where the design system defines a state but no dedicated oracle exists, fall back to the
rule oracle (tokens/system) and note it. In every state, the completeness census runs
against the oracle's inventory regardless of whether a pixel baseline exists.
## ESTABLISH a baseline when none exists — the migration case
A migration/legacy run may have NO design-phase output for a promoted UI — nothing to diff
against. Do NOT silently pass (`[NO-ORACLE]`). Establish one:
1. **Prefer an existing mockup.** If `docs/design/` already has an approved mockup for the
page (or a close gold-standard page), promote it as the baseline and note the mapping in
the manifest.
2. **Otherwise capture the current approved UI as the baseline.** Screenshot the current,
agreed-good running page at all pinned breakpoints in each access state and save the
snapshot under `docs/design/` (a `<feature>-baseline/` snapshot + a note in the design
spec). This must be ACKNOWLEDGED as the intended design — a baseline captured from a
broken page just enshrines the bug — so pair establishment with a design-system rule
check ([[fidelity-checks]]) and, where the design is user-facing-new, the designer's
approval gate.
3. **Record baseline status** in the report as `ESTABLISHED-THIS-RUN` (vs `FROZEN`) so
readers know the diff is against a freshly-captured, not a design-phase-approved, oracle.
Once established, every subsequent build is diffed against THAT baseline — the
drift-detection loop works even though the design phase was skipped.
## REFRESH a baseline when the design legitimately changed
If a diff FAILs because the design INTENTIONALLY changed (not a build regression), the fix
is NOT to relax the threshold — it is to refresh the oracle:
1. The **designer** updates the mockup + tokens/system and re-freezes the baseline
(re-running the user approval gate for a user-visible change).
2. Bump/annotate the baseline in `docs/design/` + the manifest and note `REFRESHED` in the
report.
3. Never edit application source to "make the diff pass," and never overwrite the baseline
with a build screenshot to silence a real regression — that hides drift.
## Guardrails
- The baseline lives in `docs/design/` (committed), never only in `.ai_log/` (git-ignored).
Diff images are throwaway evidence in `.ai_log/`; the baseline is durable.
- A page with no resolvable oracle is `[NO-ORACLE]`, an explicit blocking finding —
establish one, don't pass by default.