Moai Domain Design Dna

Design DNA

Most "make it look like this" requests fail the same way: the reference is looked at once, an impression is formed, and the impression is coded from memory. What survives is a vague resemblance — the palette drifts, the rhythm flattens, and the one effect that gave the reference its character is missing entirely.

This skill inserts an artifact between looking and building. The reference is first deconstructed into a Design DNA JSON, and only that JSON is used to generate. The intermediate step is what makes the result checkable: every colour, radius, and easing curve in the output traces to a recorded field, so a mismatch is a diff rather than an argument about taste.

Provenance: the three-dimension taxonomy and several extraction rules are adapted from the MIT-licensed zanwei/design-dna skill. See .claude/rules/moai/NOTICE.md for the retained copyright notice.

The three dimensions

The split matters because the three are extracted differently and fail differently.

Collapsing them loses information in both directions. A token dump with no style dimension reproduces the colours and none of the character; a mood board with no system dimension reproduces the vibe and no two elements align.

Field-by-field schema and enum vocabularies: references/dna-schema.md.

Phase 1 — Structure

When the request is for the schema itself ("what does a design profile contain?"), read references/dna-schema.md, present the three dimensions and their field groups, and ask whether any dimension should be extended or dropped before extraction begins.

Phase 2 — Analyze (reference → DNA JSON)

Read references/dna-schema.md first, then work reference by reference.

• Image or screenshot → read it directly and analyse its visual properties.
• URL → fetch the page. Prefer the source: <canvas> elements, WebGL contexts, animation-library imports, custom shaders, IntersectionObserver scroll triggers, and SVG <animate> are stated facts, where a screenshot only supports inference.
• Video or interaction capture → the only reliable source for motion timings, scroll choreography, and transition personality.

Extraction rules

1. Colour roles are assigned by dominance, not by hue. Primary is the colour holding the most area, secondary the supporting surface, accent whatever carries the calls to action. Map the neutral scale as an ordered ramp from the lightest background to the darkest text.
2. Measure radius relatively. Record it against the element height that carries it — an absolute 12px is meaningless once the button is a different size, while "half the control height" survives rescaling. The concentric-radius rule for nested surfaces is moai-ref-ui-polish's; do not restate it here, apply it there.
3. Infer type scale from ratios, not from absolute sizes. Heading-to-body ratio and line-height rhythm transfer across viewports; pixel sizes do not.
4. Density is proximity. Judge spacing from element gaps relative to the base unit, and section rhythm from whether those gaps stay constant or escalate between sections.
5. When references conflict, record the dominant pattern and name the variant. Averaging two references produces a design neither of them has.
6. Fill every field. An empty string is indistinguishable from "not looked at". Where the reference genuinely does not exercise a field, say so in the value — an explicit "not observed" is data; a blank is a gap.
7. Effects absent from the reference get enabled: false. This is the non-invention rule, and it is load-bearing: an unset flag invites the generator to add a particle field nobody asked for.
8. What cannot be identified goes in composite_notes. A screenshot shows that a surface glows without showing how. Describing the observation beats guessing the implementation and recording the guess as fact.

Output the completed JSON, then ask whether any value should be adjusted before generation.