likethat

name	likethat
description	Extract design DNA from one or more references — LOCAL repo paths and/or web URLs (a site whose mood you like) — understand the CURRENT repo's service, and synthesize a fitting mood — not a clone. Establishes a design system (DESIGN.md + tokens + real code) in the current repo. Use when the user lists local repo paths or reference URLs and wants a service-appropriate look. Triggers on "저 사이트처럼 만들어줘", "make mine like that", "이 레포들 느낌으로 디자인 잡아줘", "이 사이트 무드로 디자인 잡아줘", "참고 레포/URL에서 디자인 시스템", "establish design from these repos/urls". Provide one or more local repo paths or web URLs as arguments.
argument-hint	<ref: local-repo-path or web-url> [more ...]
user-invocable	true

likethat

Extract design DNA from reference sources — local repos and/or web URLs — understand this service, and synthesize a fitting mood — then establish it as a real design system in the current repo.

This is not clone-website. clone-website takes a URL and produces a pixel-perfect clone of that page. likethat takes references (repo paths or URLs) as palettes, reads this service's own character, and synthesizes something new that fits — not a copy of anything. A URL here is a mood reference (the vibe you want), not a page to reproduce.

The references are inputs to a creative distillation process. Their design vocabulary gets broken apart by dimension (color, type, spacing, motion, component conventions), filtered against this service's context, recombined, and applied. No single reference is adopted wholesale.

Core Principles

1. 복사 금지, 합성 필수 — No reference repo is cloned wholesale. Every value must earn its place by fitting this service.
2. 서비스가 주인 — The reference repos are palettes; the decision criterion is always "does this fit the service?"
3. 결정적으로, 한 번에 — Ask only about genuinely ambiguous choices; synthesize everything else confidently.
4. 빌드는 항상 통과 — npm run build must be green after every apply step.

Input / Output Relationship

• Current repo = the target where the mood is applied (the repo where this skill runs)
• $ARGUMENTS = one or more reference sources for design DNA extraction — each is either a local repo path or a web URL (http(s)://…). References may be mixed (e.g. ./my-app https://linear.app).
• Output = docs/likethat/DESIGN.md (single source of truth) + updated globals.css / layout.tsx + implemented/revised components

All output paths are relative to the current working repo. This skill is safe to install globally — it always writes into whichever repo it is invoked from.

---

Phase 0 — Pre-Flight Check

1. Classify and validate each reference. For each item in $ARGUMENTS: if it starts with http:// or https://, treat it as a web URL; otherwise a local repo path. For local paths, check existence/readability. For URLs, do a quick reachability check (a WebFetch GET, or a browser MCP navigation if available). Collect any invalid/unreachable references — do not abort; note them and confirm in Phase 1 if needed.
2. Detect browser capability. Check whether a browser MCP tool (Chrome / Playwright / Browserbase / Puppeteer) is available in this session. If yes, URL references can be extracted at high fidelity (computed styles + screenshot) in Phase 2; if no, URL references fall back to WebFetch. Record which mode applies.
3. Detect current repo stack. Inspect package.json, tailwind.config.*, and the source tree to identify: framework (Next.js App Router / Next Pages Router / Vite / Remix / Astro / other), Tailwind version, shadcn/ui presence, CSS approach (variables / modules / CSS-in-JS).
4. Locate the actual entry points — never assume paths. The current repo may not be a root-level Next.js App Router project. Discover, do not hardcode:
   • Monorepo? If package.json has workspaces, or there is an apps/, packages/, or pnpm-workspace.yaml, this is a monorepo. Enumerate the candidate app/package targets. If more than one plausible target exists, ask via AskUserQuestion which app/package to apply the mood to before proceeding. All discovered paths below are then relative to that target's root.
   • Global stylesheet / token entry — find the file that owns global CSS + :root tokens. Search, don't assume: src/app/globals.css, app/globals.css, src/index.css, src/styles/globals.css, styles/globals.css, app/root.tsx imported CSS, etc. Use grep/glob for @tailwind, :root, or the CSS imported by the root entry.
   • Root layout / font entry — find where fonts + the document shell live: src/app/layout.tsx or app/layout.tsx (Next App Router), pages/_app.tsx + pages/_document.tsx (Next Pages Router), app/root.tsx (Remix), src/main.tsx / src/App.tsx + index.html (Vite), src/layouts/*.astro (Astro).
   • If the repo has no recognizable web entry points, report that to the user and ask where tokens/fonts should go rather than creating root-level files.
   • No app at all? If the repo has no package.json / no web app (e.g. a docs, script, or skill-distribution repo) and the user's request implies creating one ("nextjs init", "새로 만들어줘", "build a landing page"), scaffold a fresh app as part of Phase 0: prefer a subdirectory (e.g. site/) over the repo root when the root already holds non-app files — confirm root vs. subdirectory via AskUserQuestion (recommend the subdirectory). Use the ecosystem's standard scaffolder (create-next-app etc.), run it in the background while reference analysis proceeds, and treat the scaffolded app as the discovered target for every later phase.
   • Record the concrete discovered paths — they become the Application Plan targets in DESIGN.md. Every later path (globals.css, layout.tsx, components dir, preview route) refers to these discovered paths, not the examples in this document.
5. Verify build baseline. Run the repo's build (npm run build or the equivalent for the detected tooling / target). If it fails before any changes, report to the user and ask whether to proceed anyway.
6. Prepare output directories.

   docs/likethat/
   docs/likethat/dna/
   

   Create them if they do not exist. These paths are always relative to the current repo.

---

Phase 1 — Service Interview (always runs)

Before analyzing anything, understand the service. Ask the user 2–3 focused questions via AskUserQuestion:

1. What does this service do? (one sentence)
2. Who are the primary users?
3. What tone direction do you want? Present concrete options, for example:
   • Restrained / professional
   • Playful / approachable
   • Bold / experimental
   • Minimal / neutral
   • "I'm not sure — look at the reference repos and propose options"

Simultaneously, skim the current repo's README.md, package.json name/description, and any existing routes to supplement the interview answers with observable evidence.

AFK rule: If AskUserQuestion times out or the user does not answer, do not block. Mark each question's recommended option when presenting it, proceed with those recommendations plus the repo evidence, note "answered by default (user AFK)" in the recorded service context, and surface the assumed choices prominently at the top of the Phase 5 completion report so the user can redirect. Only re-ask if a Phase 3 gate condition genuinely cannot be resolved without them.

Record the confirmed service context — it becomes the top-level filter for every synthesis decision in Phase 3.

---

Phase 2 — Parallel Reference Analysis

Dispatch one design-analyzer subagent per reference, all in parallel. Each agent analyzes only its assigned reference (a local repo path or a URL) and returns a structured Design DNA report (schema below).

Subagent type: design-analyzer Input per agent: one reference (local absolute path or web URL) + the DNA schema + a one-sentence service context summary Output per agent: DNA report markdown → save to docs/likethat/dna/<reference-name>.md (repo directory name for paths; for URLs, the slugified hostname, e.g. linear.app → linear-app — if two references would collide to the same filename, append a short disambiguating suffix)

URL references — hybrid extraction: For a URL reference, if a browser MCP tool is available (detected in Phase 0), first capture high-fidelity signals yourself with the browser — navigate to the URL, take a screenshot, and run getComputedStyle() on representative elements (body, headings, buttons, links, cards, nav) to read real color/font/spacing/radius values — then include that captured data inline in the design-analyzer dispatch prompt. The agent merges it with its own WebFetch pass. If no browser MCP is available, dispatch the agent with just the URL; it extracts via WebFetch alone and notes that limitation. (The analyzer never needs browser MCP tools itself — you capture the browser data and hand it over.)

These files are auditable artifacts — the user (or the skill on retry) can inspect exactly what was extracted, and which extraction method was used (recorded on the report's ## Source line).

Multi-platform fallback

design-analyzer is a named subagent type available on Claude. On other platforms (Copilot, Cursor, Windsurf, Codex, Gemini, OpenCode) where named subagent types are not available: inline the same role, tool constraints (read/search/Bash + WebFetch for URLs — no Edit/Write), and DNA schema into each parallel agent's prompt directly, dispatching them as standard parallel agents. For URL references, inline any browser-captured data the same way. The behavior must be identical; only the dispatch mechanism differs.

Design DNA Schema (reference for design-analyzer)

Each design-analyzer agent must return a report that follows this schema:

# <reference-name> Design DNA

## Source
<local path | url> · extraction: <file-parse | browser-mcp+webfetch | webfetch>

## Stack Detection
Framework (Next/Vite/other) · Tailwind version · shadcn presence · CSS approach (variables/modules/CSS-in-JS).
For URLs: framework hints from page markup; use N/A for anything not observable.

## Tokens
- Colors: raw palette + semantic mapping (bg/fg/primary/muted/border/...), light/dark variants
- Typography: font families (heading/body/code), size scale, weights, line-heights, letter-spacing
- Spacing: scale (4/8/12/16/24...), section padding patterns
- Border radius: buttons/cards/inputs/avatars
- Shadow/elevation, borders
- Motion: default transition values, keyframes, easing, scroll/hover conventions

## Layout Patterns
Container max-width, grid/flex conventions, responsive breakpoints, sticky/z-index layers

## Component Conventions
Frequently used primitives, variant naming, composition patterns (e.g., card = image + title + meta)

## Voice & Copy Tone
Tone extracted from actual string samples (formal/casual, length, emoji use, CTA style)

## Visual Language & Imagery
Backgrounds (gradient mesh, aurora/glow, line/dot grid, noise) · product imagery (screenshots, SVG app mockups, charts/sparklines) · 3D / illustration / generative motifs · decorative marks · icon library + style (stroke weight, filled vs outline, size) · overall imagery density (visual-heavy vs text-heavy)

## One-Line Mood Summary
"This reference's mood is ___ (e.g., calm neutral + generous spacing + serif headings)"

Values must come from actual code, browser-captured data, or fetched markup — no guessing. If a value cannot be found, write "N/A".

---

Phase 3 — Synthesis + Ambiguity Gate

With all DNA reports collected and the service context confirmed, synthesize one coherent direction.

Synthesis Rules

• Service context is the first-pass filter. Every candidate value from the reference repos must pass: "does this fit this service's tone?" Values that don't fit are adapted (adjust saturation, roundness, weight) or discarded.
• Decompose by dimension, not by repo. Pick color from ref-A, typographic rhythm from ref-B, spacing generosity from ref-C. Never adopt one repo wholesale.
• Resolve conflicts with service tone. When references disagree (e.g., one is light-first and another is dark-first), the service context decides. If the service context cannot resolve it, trigger the gate.

Gate Conditions (stop and ask only when one of these is true)

1. The user answered "I'm not sure / propose options" for tone in Phase 1 — present 2–3 direction options with mini-previews.
2. References genuinely conflict on a mood dimension AND the service context cannot resolve it (e.g., minimal vs. expressive, dense dashboard vs. spacious landing).
3. A service-critical fork exists with roughly equal evidence on both sides (e.g., dark-first vs. light-first).

Each option in a gate response must include a mini-preview: representative 3 colors (as color swatches or hex values) + heading font + one-sentence mood description.

Outside these three conditions, synthesize confidently without asking.

Output

Write the confirmed direction to docs/likethat/DESIGN.md using this structure:

# <Service Name> Design System

## Service Context (confirmed from interview)
What / for whom / desired tone

## Mood Statement (3–4 sentences)
The mood this service is aiming for, in language. Which reference contributed what,
and what was adapted to fit the service.

## Tokens (confirmed values)
Color semantic mapping (light/dark, oklch) · Typography scale · Spacing · Border radius · Shadow · Motion
→ Each value annotated with provenance: "adopted from ref-A / desaturated to match service tone"

## Layout System
Container/grid/breakpoints/z-index rules

## Visual Language (REQUIRED — do not skip)
The concrete visual treatment that keeps the result from looking like a generic
text-and-cards template. Decide and record each:
- **Backgrounds / atmosphere:** generative gradient mesh, aurora/glow, dotted or line grid,
  noise/grain, section dividers — what carries depth behind the content.
- **Product / feature imagery:** how the product is shown — SVG app-window mockups, charts/
  sparklines, kanban/diff/timeline illustrations (NOT just text rows).
- **Iconography:** library + style (stroke weight, filled vs outline, size), plus any custom
  SVG marks (logo strip glyphs, feature icons).
- **Decorative motifs / illustration:** abstract SVG shapes, 3D/isometric hints, brand marks.
- **Imagery sourcing:** original SVG/CSS (default, license-safe) and/or generated raster
  images (note the tool + prompts). Never leave sections flat when the references are visual.

## Component Inventory
Representative components to apply/create in the current repo + mood-application guidance per component.
Include the visual/illustration components from Visual Language (backdrops, charts, mockups, marks) — not only text sections.

## Voice & Labels
Copy tone guide + key label/CTA examples

## Application Plan
Concrete target paths discovered in Phase 0 (NOT assumed): tokens → <discovered global stylesheet>,
fonts → <discovered root layout/font entry>, components → <discovered components dir>,
preview → <framework-appropriate route>. For a monorepo, all paths are under the chosen target app/package.

---

Phase 4 — Application (worktree-parallel)

Apply the confirmed DESIGN.md in two stages.

Stage A — Sequential Foundation (do this yourself, not delegated)

Write to the entry points discovered in Phase 0 (recorded in the DESIGN.md Application Plan) — never assume src/app/*. The paths below are illustrative; use the repo's real ones.

1. Update the discovered global stylesheet / token entry (e.g. src/app/globals.css, src/index.css, app/globals.css) with the confirmed color tokens (oklch variables, light/dark blocks). Match the file's existing CSS approach (CSS variables vs. Tailwind @theme vs. config).
2. Update the discovered root layout / font entry (e.g. src/app/layout.tsx, pages/_app.tsx, app/root.tsx, src/main.tsx) with the confirmed fonts, using the framework's idiomatic font mechanism (next/font for Next, <link>/@font-face otherwise).
3. Update any shared type definitions or utility classes that the component work depends on.
4. Verify: the repo's build passes (first green gate).

Stage B — Parallel Component Application

Dispatch one design-applier subagent per component/layout in the Application Plan. Each works in its own git worktree branch. As each completes, merge into main and run npm run build — matching the clone-website worktree-merge pattern.

Non-git fallback (disjoint file ownership): If the target is not a git repository (or worktrees are otherwise unavailable), skip worktrees entirely. Instead, give every agent an exclusive, non-overlapping set of files it owns — no two agents may touch the same path — and have them write in-place. Any file that composes the agents' outputs together (e.g. page.tsx, route files, barrel exports) is written by the orchestrator itself after all agents complete. The per-merge build gate becomes a single build after composition.

Subagent type: design-applier Input per agent (inline — never "go read the doc"):

• The relevant section from DESIGN.md (tokens + mood statement + component spec)
• The Visual Language treatment for this component — the specific backdrop, chart/sparkline, SVG product-mockup, illustration, or brand mark to build. A section must NOT ship as flat text + a bordered box when the references are visual.
• Target file path (e.g., src/components/HeroSection.tsx)
• Shared imports available: cn(), src/components/icons.tsx, shadcn primitives, and the shared visual primitives (see below)
• Responsive rules (breakpoints + what changes)
• Instruction: pass npx tsc --noEmit before finishing
• Concurrency note (required wording when agents share one tree, i.e. the non-git fallback): "Other agents are writing OTHER files concurrently — tsc may report transient errors in files you don't own. Ignore those; YOUR files must produce zero errors." Without this, agents chase phantom errors from half-written sibling files.

Build shared visual primitives first. Before (or alongside) Stage A, create a small visuals module (e.g. src/components/visuals.tsx + CSS utilities in the global stylesheet) with reusable, original SVG/CSS assets from the Visual Language: generative backdrop (grid + aurora/glow + grain), Sparkline/chart, app-window/kanban/diff mockups, and brand/feature marks. Section builders import these so every section has real visual substance, not just text.

Merge discipline: Merge worktree branches as they complete. Resolve conflicts using full context (you know what each agent built). After every merge: npm run build must be green.

Scope cap: If a component spec exceeds ~150 lines, split it into smaller tasks and dispatch more agents. Do not let a single design-applier carry too much scope.

Multi-platform fallback

On platforms without named subagent types: inline the design-applier role (Edit/Write/Bash tools, spec inline, worktree instructions, npx tsc --noEmit gate) into each parallel agent's prompt. Behavior is identical; only dispatch mechanism differs.

---

Phase 5 — QA + Preview

Build Verification

npm run build must be green. If it is not, diagnose and fix before proceeding.

Preview Route (default-on — temporary dev route)

Create a design system preview page at a framework-appropriate route under the target discovered in Phase 0 — e.g. src/app/design-preview/page.tsx (Next App Router), pages/design-preview.tsx (Next Pages Router), app/routes/design-preview.tsx (Remix), src/pages/DesignPreview.tsx + a route entry (Vite/React Router), or src/pages/design-preview.astro (Astro). If the repo has no routing convention you can safely target, skip the route and instead write a standalone docs/likethat/preview.html and tell the user. This preview is:

• Temporary — a dev/review aid, not a production page. Mark it clearly with a banner or comment.
• Default-on — created automatically so the user can immediately review the design system in context.
• Contents: color palette swatches, typography scale samples, spacing scale, border radius examples, representative component variants, motion samples (if applicable).

The user can delete this route before shipping to production.

Design Polish Loop (mandatory when references are visually rich)

A blind, text-spec, multi-agent build lands at "clean, competent template" — not "beautiful." That gap is the difference between a demo the user shrugs at and one that hooks. Close it with a critique-and-refine loop BEFORE completion:

1. Run the app (dev or prod server) and capture full-page + hero screenshots at desktop (1440) and mobile (390) with a browser MCP / headless browser (e.g. gstack browse). If no screenshot tool exists, say so and ask the user to eyeball it.
2. Score the screenshots against this beauty rubric — rate each 1–5, name the weakest 2–3:
   • Focal visual — is there a striking hero graphic / product panel that hooks within 2 seconds, or a small timid box?
   • Depth — layered glass, multi-stop gradients, glow, light-catching gradient borders — or flat fills?
   • Motion — animated backdrop (drifting aurora), entrance choreography, hover micro-interactions, drawn-in charts?
   • Layout rhythm — varied (bento, asymmetry, differing section shapes), or the same centered-heading → even-grid repeated every section?
   • Type drama — display scale, tight tracking, gradient/accent treatment on the headline?
   • Color life within the mood — accent glows, gradients — alive, not monotone?
3. Fix the weakest items in code, rebuild, re-screenshot. Iterate 1–2 rounds until the page would make the target user stop scrolling. If a design-review tool is available (e.g. gstack /design-review), run it here.
4. Only then finish. Never ship the first blind build as final — the screenshot critique is required whenever the references are visually rich.

Completion Report

Report back with:

• Number and kind of references analyzed (local repos and/or URLs)
• Confirmed mood summary (3–4 sentences from DESIGN.md)
• Files created or modified (tokens, fonts, components, DESIGN.md) — at their actual discovered paths
• Build status (build result)
• Link to the preview route (the framework-appropriate path created, or the docs/likethat/preview.html fallback)
• Any known gaps or open decisions

---

Pre-Dispatch Checklist

Before dispatching any design-applier agent, verify all boxes:

• docs/likethat/DESIGN.md is written and confirmed, with concrete discovered entry-point paths in its Application Plan
• docs/likethat/dna/<reference-name>.md exists for every reference (repo or URL)
• Stage A foundation applied to the discovered global-stylesheet + root-layout entry points, and the build is green
• Component spec is inlined in the agent prompt — no "go read the doc"
• Target file path is specified (from the discovered structure, not assumed src/app/)
• Responsive rules are specified
• Spec is under ~150 lines; if over, split the task

What NOT to Do

• Do not adopt any reference repo wholesale. The synthesis must produce something new.
• Do not ship flat, text-only sections when the references are visually rich. Endel/Linear/Raycast-class references lean on generative backgrounds, product mockups, charts, and illustration. Build original SVG/CSS assets (backdrops, sparklines/charts, app-window/kanban/diff mockups, brand marks) — a page of bordered boxes with centered text is a failure even if the tokens are right.
• Do not skip the service interview. Without service context, the synthesis has no first-pass filter.
• Do not hardcode absolute paths in any output. All docs/likethat/ paths are relative to the current repo.
• Do not assume a src/app/ Next.js App Router layout. Discover the real global-stylesheet and root-layout/font entry points in Phase 0 (they may be src/index.css + src/main.tsx for Vite, app/root.tsx for Remix, pages/_app.tsx for Next Pages Router, or under apps/<name>/ in a monorepo). Creating root-level src/app/* files in a repo that doesn't use that structure is a defect.
• Do not guess the monorepo target. If multiple apps/packages could be the target, ask which one before writing anything.
• Do not dispatch design-applier agents before Stage A is green. Components depend on the token foundation.
• Do not send agents to read DESIGN.md themselves. Their spec must be inline in the prompt.
• Do not let the build go red between merges. Fix TypeScript/CSS errors immediately after each merge.
• Do not confuse this skill with clone-website. clone-website is for URL → pixel-perfect clone of that page. likethat is for references (local repos and/or URLs) → synthesized service-fitting mood.