Derive a full UI palette from one or two brand colours — state variants, brand-tinted greys, semantic colours. Use when building or expanding a colour system.
日本語の概要は準備中です。原文の説明を表示しています。
Rebuild a live web page 1:1 from measurement into Figma, Penpot or code, then verify it. Use when reproducing a page or checking a rebuild against the original.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
One-click cloners return a lookalike: it resembles the page, and nothing in the process ever checked whether it matches it. This skill produces a different artifact — values traceable to the source, and a diff that says what is still wrong.
The one rule: if the page states a value, read it. If it does not, and only then, decide it. A rebuild done that way is finished when the diff is empty, which you can check, rather than when it looks about right, which nobody can.
Only the rebuild step cares whether the target is Figma, Penpot or a codebase. Everything else is the same job.
Drive a real browser and take four things at once: full-page screenshots at both widths, the rendered DOM, the computed styles of each section, and the asset URLs the page requested. On a client-rendered page this is the only capture that contains anything at all.
Rendered state is the specification, not the file the server sent.
Markup carries text verbatim and names every asset URL without a screenshot in the loop.
wget -r -l 3 -k -p -E -nc https://example.com/page
Host-spanning is left out on purpose: CDN assets stay unfetched, their URLs are
in the markup, and they get downloaded directly at step 4. wget does not run
JavaScript, which is why it is the second capture and not the first.
Read the tokens off the live page rather than off a picture — the type scale,
palette and spacing are already declared. Use [[extract-design]] for the
extraction; --design-md gives you a brief you can hand straight to the
rebuild step.
Parse headings, body copy, numbers, lists, links and the footer out of the DOM, then download every referenced asset. Never retype a string and never infer a value the source states. Nothing retyped means nothing drifts.
One section at a time — header, hero, feature rows, tables, media, testimonials, FAQ, footer — in auto layout or real layout containers, never pinned coordinates. Screenshot each section and compare it before moving on. A rebuild judged only at the end gets judged once, badly.
| Check | Question |
|---|---|
| Visual | Does it look the same at each width? |
| Structural | Is it built from sane containers rather than absolute positions? |
| Semantic | Are the words, links, numbers and variants the ones the source states? |
The third is the one people drop, and it is the one that matters most. A perfect visual copy can carry wrong data, and it will pass every screenshot comparison you run against it.
Token-level verification is free: extract the original, extract the rebuild, compare the two token sets. The difference is your remaining work, stated as a list instead of a feeling.
Some errors are structural blindness, not degradation, and none of them look like errors:
Report what you could not resolve rather than guessing.
Licensed foundry fonts usually cannot be loaded in an automated environment, and a visual lookalike is the wrong answer because it moves every line break you are about to verify. Build on a metric-compatible stand-in, then swap to the real face at the end with one find and replace.
Every remaining error is local, so the instruction has to be local too: name the section, name what is wrong, name the source value. Rerunning the whole rebuild to fix one card costs the hour again and moves the errors somewhere new.
Where the fix is a judgement call rather than a value, produce two or three versions of that one section and ask which is right — and ask what made it right. That sentence is what gets applied to the next section instead of a guess.
Import gone, staging assets gone. What is left is the two frames, named layers, icons as vectors, not one absolutely positioned element. If the import is still in the file, the file is still a draft.
Reproducing a page is research: teardowns, redesign baselines, migration references, and regression checks against your own site. The last is the most undervalued — the fastest way to learn whether production still matches its design system is to extract it and compare.
Shipping someone else's layout, copy or brand as your own is a different act, and the pipeline being fast does not make it a better idea. Respect robots.txt and terms of service.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Derive a full UI palette from one or two brand colours — state variants, brand-tinted greys, semantic colours. Use when building or expanding a colour system.
日本語の概要は準備中です。原文の説明を表示しています。
Top bar, app launcher, tenant and environment cue, status bar. Use when designing the persistent shell or navigation between apps behind one login.
日本語の概要は準備中です。原文の説明を表示しています。
Product visuals must show the real product with real data. Use when building landing pages, hero sections, screenshots or demo panels.
日本語の概要は準備中です。原文の説明を表示しています。
Shape language across type, radius and icons carries brand personality. Use when starting a design system, picking icons or radius tokens, or reviewing visual consistency.
日本語の概要は準備中です。原文の説明を表示しています。
Rest, hover, active, focus, disabled and loading states, derived from the base colour. Use when designing buttons, links, inputs or any clickable component.
日本語の概要は準備中です。原文の説明を表示しています。
Light, dark or both, and when a theme selector is worth it. Use when defining a base palette or deciding on dark mode support.
日本語の概要は準備中です。原文の説明を表示しています。