design-acquire

name	design-acquire
description	Resolve a design handoff into something measurable: parse a handoff prompt, unpack an exported HTML/zip, pull tokens from a design-system source, or record an honest degraded mode for screenshots-only input. NOT for the implementation workflow itself (that's design-implement) and NOT for measuring a diff (that's design-verify).
version	0.1.0
owner	swarmery-core
docs	{"status":"reviewed","source_sha":"be52051a970c","updated":"2026-08-06T00:00:00.000Z"}

Purpose

Phase 1 of design-implement. Four input shapes arrive in practice, and they do not promise the same thing: only a self-contained HTML export is ground truth for geometry. This skill turns whatever arrived into a path plus an honest statement of what that path can support, and hands both back. It does not extract tokens (Phase 2) and it does not measure anything (design-verify).

The export route in Claude Design

This is the part operators do not find on their own — reproduce it for them exactly:

In Claude Design (claude.ai/design) open the project → the Share menu in the top right corner → the Export section → then either Claude Code — "Implement this design in code" → Send (sends the handoff prompt into the Claude Code session), or Project HTML → Download (downloads a .zip with self-contained HTML/CSS). Pixel work needs Project HTML specifically: the handoff prompt describes intent, while the .zip contains what actually renders.

Input shape 1 — a handoff prompt

The operator pasted a design tool's handoff prompt (or it arrived through Send).

1. Parse it. Look for a reference to a file or a URL carrying the actual markup.
2. If the prompt leads to HTML — fetch it and continue with shape 2. The prompt's prose is context, not a substitute.
3. If it does not — ask for Project HTML and show the route above. A handoff prompt on its own describes intent: it states what the screen means, not the computed values it renders at, so nothing downstream can be measured against it.

Promises: intent and structure. Not geometry, not exact values.

Input shape 2 — a .zip or .html export

1. Unpack into the working directory: .design-verify/source/<slug>/.
2. Find the entry document (the top-level index.html, or the single .html at the root of the archive; if several are plausible, list them and let the operator pick — do not guess which screen is meant).
3. Check self-containment: scan for external network resources (remote stylesheets, webfonts, images, script tags pointing off-host). Record every one of them. They change what renders, so they change the measurement — a font fetched from the network that fails to load in the headless run silently reshapes every text block.
4. Pass the entry document's path forward.

Promises: full ground truth. This is the shape the rest of the pack is designed around.

Input shape 3 — DesignSync or a design-system project

Pull tokens and components through whichever tool is available for that source.

Record the split honestly: the tokens are trustworthy; the geometry of a specific screen is not. A design system says what a button is; it does not say where this screen puts it, how much space is above it, or which of its variants this layout uses. If the goal is a pixel match for a screen, an HTML export is still required — route above.

Promises: the token layer (colours, type, spacing, radii). Not screen layout.

Input shape 4 — screenshots only

State this in full, as its own paragraph, before any work starts:

Pixel accuracy cannot be guaranteed from images. Exact type size and tracking are not recoverable, real colour values are not recoverable after compression, and states (hover, focus, active, disabled) are not present at all. Ask for an HTML export instead — the route is above.

If the operator insists, continue — but:

• record the mode as degraded: screenshots in the Phase 4 plan and in the final report;
• never claim a pixel match, at any point, in any wording;
• in Phase 6 the implementation is compared against the screenshot as an approximate reference, and the result is reported as an approximation, with that word in it.

Promises: an approximation, labelled as one.

Working directory

Everything this skill writes goes under .design-verify/ in the project root — sources in .design-verify/source/<slug>/, later phases add their own subdirectories.

Check the project's .gitignore for .design-verify/ and remind the operator to add it if it is missing. These are large, regenerable, machine-produced artefacts; they do not belong in the history.

Output back to design-implement

• the design path (entry document, or the screenshot set);
• the input shape and the mode (degraded: … when applicable);
• external network resources found in shape 2;
• for shape 3, an explicit note that screen geometry was not acquired.

How to use

What it does

You have a design handoff — a pasted prompt, a downloaded .zip, a design-system link, or just screenshots — and you need to know what it can actually support before anyone writes code. This skill resolves that input into a concrete path on disk plus an honest statement of what that path promises: full geometry, tokens only, or an approximation. It stops the common failure where a screenshot gets treated as ground truth and a "pixel match" is claimed over something unmeasurable.

When to use it

• An operator handed you a design export and you need to unpack it and find the entry document before implementation starts.
• Someone pasted a design tool's handoff prompt and you have to work out whether it leads to real markup.
• You have only screenshots and need the degraded mode written down before anyone promises accuracy.
• The design lives in a design-system source and you need the token layer pulled without over-claiming screen layout.

When not to use it

• You want the full implementation workflow end to end — use design-implement, which calls this skill as its first phase.
• You already have a built screen and want it measured against the design — use design-verify.
• You are checking UI behaviour with no reference design at all — use browser-verification in core.

How to invoke

Skill(skill: "design-pack:design-acquire")

Invoke it with the handoff you received — a file path, an archive, a URL, or a description of what arrived. It reads the input, picks the matching shape, and does the unpacking or the asking from there.

Inputs

• The handoff itself — a .zip or .html path, a URL, a pasted handoff prompt, a design-system reference, or a set of screenshots — required.
• A screen or slug hint — which screen is meant, when an archive contains several plausible entry documents — optional; you get asked if it is ambiguous and cannot be inferred.

What you get back

Sources unpacked under .design-verify/source/<slug>/ in the project root, and a short handoff back to the caller containing: the design path (entry document or screenshot set), the input shape and mode (degraded: screenshots when applicable), any external network resources found in an export, and — for a design-system source — an explicit note that screen geometry was not acquired. You also get a reminder to add .design-verify/ to .gitignore if it is missing.

Worked example

Skill(skill: "design-pack:design-acquire")
> input: ~/Downloads/project-html-export.zip, screen "orders/line-items"

The archive is unpacked to .design-verify/source/orders-line-items/, the entry index.html is identified, and a scan finds one remote webfont. You get back the entry path, shape "HTML export — full ground truth", and the webfont flagged as a resource that will reshape text if it fails to load in the headless run.

Related

• design-implement — the whole workflow; start there unless you only need the input resolved.
• design-verify — measures a built screen against the design once implementation exists.
• browser-verification — behavioural UI checks when there is no design to measure against.