Snapshot a URL

Point preset AI at a public URL. The scanner renders the page in headless Chromium, walks every visible element, and synthesizes a DesignSystemSnapshot you can refine into your own design system. Useful when you do not have a codebase to scan: agencies onboarding from a client's live product, brand teams capturing a launched site, designers extracting tokens from a reference.

When to use the URL lane

The four lanes produce the same shape of output. They differ in what signal they can reach. The URL lane is the only one that captures rendered values: what the browser actually paints, including resolved CSS variables, theme overrides, and runtime-computed styles.

Run the snapshot

From your terminal:

preset snapshot --url https://stripe.com

The first run downloads Chromium via Playwright (~120MB, one-time). After that, a snapshot typically completes in 10-30 seconds depending on the page.

Typical output:

✓ Rendering stripe.com and capturing computed styles...
✓ Snapshot generated in 18,420ms (3,847 nodes visited)

Coherence score: 67 / 100
Colors:        24 primitives, 8 semantic roles
Typography:    6 type styles
Spacing:       8 distinct values
Components:    37 candidate patterns

Flags

What the scanner captures

For every visible element on the page, the scanner reads the computed-style values for these properties:

• Color: color, background-color, the four border-*-color channels, plus SVG fill and stroke (filtered to elements actually inside an <svg> so unrelated nodes don't pollute the palette).
• Radius: the four border-*-radius corners.
• Typography: font-family, font-size, font-weight, line-height, letter-spacing.
• Spacing: padding-top/right/bottom/left, margin-top/right/bottom/left, gap, row-gap, column-gap.
• Effects: box-shadow.

Each observation carries a surface context, element tag, parent tag, class list, ARIA role, position type, viewport coverage, which the surface-type classifier uses downstream to distinguish core-UI tokens from illustration, brand, marketing, and data-viz palettes. The primitive palette comes from core-UI observations only, so a brand wordmark or a chart's color scheme cannot accidentally become a primitive.

Visibility filter

Hidden elements are skipped. An element is visible if it has display !== 'none', visibility !== 'hidden', opacity > 0, and a non-zero bounding box.

Scroll-and-wait

After initial network-idle, the scanner scrolls the page in 200px increments (up to 6 seconds) to fire lazy-loaded content, then settles for 1.5s before sampling. Pages with heavy hero animations or IntersectionObserver-driven content reveal will still be captured.

CSS-variable name recovery

The scanner also reads every accessible stylesheet's source CSS and recovers symbolic variable names (--brand-primary, --surface-bg) so that a captured rgb(99, 102, 241) traces back to its declared name. Cross-origin stylesheets are fetched server-side. Sites that declare tokens on :root (shadcn/ui, most design-token codebases) get high recovery rates.

What it cannot capture

Accuracy expectations

The URL lane gives you the rendered view, not the source view. Two things to keep in mind when comparing a URL snapshot to a codebase snapshot of the same product:

1. Values are computed, not symbolic. A button with background: var(--brand-primary) shows up as rgb(99, 102, 241) until variable-name recovery resolves it. Recovery works for :root-declared variables on accessible stylesheets; theme-scoped overrides (.dark { --brand-primary: ... }) won't always round-trip.
2. Coherence scores will differ. The codebase lane sees bg-primary 47 times across Button, Link, and Badge and reports high reuse. The URL lane sees 47 instances of rgb(99, 102, 241) and reports it as a frequently-observed color. Both are true; they measure different things. Don't compare scores across lanes: they're not the same metric.
3. Rendered state is a moment in time. The page you snapshot today may show different content tomorrow. The tokens it exposes (palette, type scale, spacing rhythm) are usually stable; the specific observation counts are not.

For most use cases, bootstrapping a starter DS from a live product, capturing a reference, comparing two brands, the URL lane gives you the right starting point in a few seconds. For deep audit work on your own product, prefer the codebase lane.

robots.txt and the user agent

The scanner identifies itself with the user-agent token PresetBootstrapper. Before rendering, it consults <origin>/robots.txt and respects Disallow rules. If the target path is disallowed, the scan returns a structured opt-out (exit 0 on CLI, 403 robots_opt_out on the API): not a failure.

If your site uses preset AI internally and you want to allowlist the scanner:

User-agent: PresetBootstrapper
Allow: /

If you want to block the scanner:

User-agent: PresetBootstrapper
Disallow: /

If your robots.txt is missing, empty, or unreachable, the scanner treats that as "no restrictions stated" per the Robots Exclusion Protocol: it does not punish a flaky CDN.

The CLI's --ignore-robots flag bypasses the check. It exists for the user's own sites (private staging, internal tools where robots.txt is generic) and is intentionally not exposed in the web UI.

How the four lanes compare

The PDF lane is the most recent addition. Pick it when you have a brand-guidelines PDF but no public site or codebase yet.

What's next