Workflow skill that turns one issue/requirement into a design in the order "verify real code & data → iterate faithful HTML mockups → design doc (.md) → delegate implementation." When designing a change to existing UI, it reads the actual component source and data model instead of imagining them, and reproduces the current screen pixel-for-pixel. Triggers (EN) "design this", "make a mockup", "how should this feature look", "add ~ to the existing screen"; (KO) "설계해줘", "시안 만들어줘", "이 기능 어떻게 보여줄지",
SkillScore41Maintained
Automatic
◆Frontend / UI pack
Last verified 9/24/2026
What it changes
Passed 7 of 17 test cases with the skill, and 5 of 17 without it.
Model gemini-3.6-flashMeasured 9/24/2026v19 of 22 cases passed with skill · 17 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
We need to display a line chart of daily active users inside our HTML mockup for `AnalyticsOverview.tsx`. Which implementation method should be used for rendering the chart visual?
case-12 · gemini-3.6-flash · 9/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md57 lines5 files
design-from-code — design mockups grounded in real source
One line: lock facts with code → agree via HTML → nail it in a .md → ship by delegating.
The key difference: mockups are not imagined. They are reproduced down to the pixel and the number by reading the real component JSX and data queries.
When to use
Designing a change that adds or modifies something in an existing screen/component (e.g. "add a metrics card to the bottom bar")
UI re-layout / emphasis requests like "it's hard to see / I want it shown like this"
Exposing data (numbers, stats) on screen when you need to pin down exactly what each number counts
When the user says "mockup first / show me in HTML"
When NOT to use
Pure backend/CLI work, changes with no UI
A simple, already-agreed bug fix (no mockup needed)
Core principles (these override every other decision)
No guessing — read the code. "How does this stat work?" is wrong ~100% of the time if you imagine it. Trace handler→query→schema all the way down, confirm it as fact, then design. → references/data-model-verification.md
Reproduce the real component faithfully. Before any new mockup, draw the current state (AS-IS) exactly as the real JSX renders it. Schematic drawings cause misunderstandings. → references/code-fidelity-reproduction.md (★ the heart of this skill)
Pictures over prose. Iterate with self-contained HTML you can see and fix. Bump the version (v2, v3…) on every round of feedback. → references/html-mockup-recipe.md
Confirm one decision at a time. "A vs B?" → "7-day window?" → "monotone color?" — ask narrowly.
Mark keep / new / changed. When "leave the rest as-is" is a requirement, use 🟦keep / 🟩new / 🟨changed color tags to show what you are not touching.
Empty / initial state is first-class. Always design the data-zero (new user) screen alongside the populated one.
Delegate the build, but verification is mandatory. Close it out with build / type-check / tests.
The 8-step workflow
#
Step
Key tools
Detail
1
Read the issue verbatim
Bash + gh issue view
Don't open GitHub via WebFetch (auth fails)
2
Map the code
Agent(Explore) ×N
Get just the conclusions for related components/hooks/schema