From ant-common-kit
UI 컴포넌트/레이아웃을 글이 아니라 "보고 골라서" 정하는 시각적 프로토타이핑 토너먼트. 화면에 무언가를 어떻게 표현할지(카드, 목록 행, 패널, 컨트롤, 빈 상태 등) 정해야 할 때, 프로젝트의 실제 테마 토큰 (팔레트·폰트·radii)을 재사용한 단일 오프라인 HTML로 20–30개의 서로 다른 시안을 생성하고 — 브라우저에서 체크박스로 투표 → 당선작을 잠긴 탭으로 이월 → 빈 슬롯을 새 시안으로 재생성하며 N라운드 반복해 최종안으로 수렴시킨 뒤 실제 코드에 반영한다. UI 옵션을 탐색/비교하거나, 컴포넌트를 프로토타이핑하거나, 레이아웃이 어색(너무 길다/비었다/복잡)해서 커밋 전에 대안을 보고 싶을 때 사용. 언어 무관 — 예: "컴포넌트 POC", "시안 만들어", "프로토타입", "디자인 시안", "카드 타입", "여러 개 만들어서 고르자", "투표해서 고르자", "시안 비교", "component POC", "design bake-off", "compare layouts", "show me options".
How this skill is triggered — by the user, by Claude, or both
Slash command
/ant-common-kit:component-prototypeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Decide UI by **looking and picking**, not by describing in prose. Generate many native-looking
Decide UI by looking and picking, not by describing in prose. Generate many native-looking variants, review them in a browser, vote, keep winners, regenerate the rest, repeat until it converges. Each round is a single self-contained HTML file the user opens directly.
The interactive plumbing — voting checkboxes, candidate/finalist tabs, sample toggle, persistence,
clipboard export — is shipped in assets/poc-shell.html. You never rewrite it. Each round you
author only a small data file (theme tokens + variant render functions) and inline it with
scripts/build_poc.py. Contract & worked example: references/data-contract.md (read it before
authoring your first data file).
brief + extract theme → round 1: 20–30 variants → user votes (copies JSON) →
you ingest kept[] → round N: locked picks in finalists tab + fresh variants for the empty slots →
… repeat, walking the stage ladder coarse → fine, until one design remains → finalize into real code
Variation walks from the biggest structural swings down to the finest CSS detail. The stage is driven by what the user has locked in, not by the round number — a stage can span several rounds, or be skipped if the user converges fast. Never hardcode "round 1 = layout, round 2 = CSS."
The gradient (and each stage itself runs coarse → fine across its own rounds):
desc (헤더: 모노+복사 / 칩: 솔리드 알약 / 액션: 텍스트링크) so the
user can cherry-pick across cards fast: "r4-07의 칩 + r4-03의 헤더 + r4-12의 액션." Maximize
cross-element diversity — the goal is SPEED of assembly, not one finished look.When the user makes a composite/assembly request, synthesize the named parts into one assembled candidate next round (carry it as a finalist), then keep varying the still-undecided parts around it.
Why this matters. Stages 1–4 swing CSS at the whole-variant level, so a hero sub-element (e.g. the role chip) can ride through every round unchanged — worsened if you collapse it into one shared helper, which erases the variation seam. If a reviewer asks "왜 이 칩은 하나도 안 변했어?" or "전부 다 다르게 섞어줘," switch to the parts-catalog mode above. See the per-part skinning recipe in
references/data-contract.md.
Advance only on a lock signal. Read the vote + rationale each round: when the user signals the
current level is decided ("이 레이아웃이다", "배치 확정", "이 색감/스타일이다"), freeze it and step to the
next stage. If the picks still disagree at the current level, run another round at the same stage,
with smaller amplitude than the last. If a later stage reopens an earlier doubt, step back up.
Whatever is locked is baked into every new variant (and carried in finalists); only the current
level varies. Carry the active stage in roundIntent so the page header shows what this round is for.
theme/tokens.ts, ConfigProvider), Tailwind config, CSS custom properties,
a design-tokens file, or the most-used colors/fonts in existing components.themeCss (a raw :root{…} block + any reusable classes) and record where you
got them in themeSource. This step is what makes the POC trustworthy — never skip it.Write poc-data.js defining window.POC_SPEC per references/data-contract.md:
title (stable across rounds — it's the localStorage key), brief, round,
roundIntent (the active stage, e.g. "레이아웃 파격" / "CSS 섬세"), themeCss, themeSource.samples: the states from step 1 (include an overflow case and an empty/placeholder case).candidates: 20–30 genuinely distinct variants for the current stage (see the Stage ladder),
at an amplitude finer than the previous round in this stage. Round 1 starts at 레이아웃 파격 —
different skeletons (list ↔ chips ↔ tabs ↔ grid ↔ table ↔ cards), controls relocated; not chip restyles.
Once a level is locked, bake it into every variant and vary only the current level. Give each a
short Korean title + desc and a globally-unique id prefixed by round (r1-01, r2-01, …).
render(data, i) returns HTML using the theme CSS vars.finalists: empty on round 1; on later rounds, the kept variants from the previous round
(copied verbatim with their ids and render fns).python "<skill>/scripts/build_poc.py" --data poc-data.js --out poc-round-1.html --open
Write poc-data.js and the output HTML into a throwaway spot in the user's project (e.g. a
.poc/ dir at repo root, or alongside the target file). Then tell the user: review in the browser,
check the variants you like, and click 결과 JSON 복사 → paste it back in chat (adding any
rationale in their own words). (Per-card votes persist in localStorage, so reloading is safe.)
When the user pastes { title, round, kept: [{ id, name, desc }, …] }:
ids become the next round's finalists (carry their objects forward verbatim).roundIntent. If picks still disagree, stay at
this stage and make the next batch finer-amplitude. Step back a stage if a later round reopens an
earlier doubt.candidates (new round prefix) for the (possibly advanced) stage — push the
liked direction, drop dead ends.--out poc-round-2.html) and have them vote again.Stop when one design remains, or the user picks a winner / says done.
code-convention skill / CONVENTIONS.md exists, follow it — testids, i18n, naming, a11y).brain/,
drop a one-line decision note (what won, why, which round) and link it from the relevant MOC..poc/ scratch files (they're throwaway).file:// with no network — all CSS/JS
inline, no external fonts/stylesheets (system-font fallbacks are fine).title (votes
are keyed on it). New variants always get a new round-prefixed id..poc/
or clean up at finalize). Only the finalized component lands in the codebase.assets/poc-shell.html — the reusable page shell (voting, tabs, sample toggle, export). Don't edit per-round.scripts/build_poc.py — inlines a round's poc-data.js into the shell → standalone HTML (--open to launch).references/data-contract.md — POC_SPEC shape, export shape, and a worked example. Read before authoring.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub poorants/ant-skills --plugin ant-common-kit