| 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).
- Parse it. Look for a reference to a file or a URL carrying the actual markup.
- If the prompt leads to HTML — fetch it and continue with shape 2. The prompt's prose is
context, not a substitute.
- 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
- Unpack into the working directory:
.design-verify/source/<slug>/.
- 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).
- 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.
- 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.
