메뉴
This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns).
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | interface-design |
| description | This skill is for interface design — dashboards, admin panels, apps, tools, and interactive products. NOT for marketing design (landing pages, marketing sites, campaigns). |
Build interface design with craft and consistency.
Use for: Dashboards, admin panels, Software as a Service (SaaS) apps, tools, settings pages, data interfaces.
Not for: Landing pages, marketing sites, campaigns. Redirect those to
/frontend-design.
The model will generate generic output. Model training has seen thousands of dashboards. The patterns are strong.
The entire process below can be followed: explore the domain, name a signature, state the intent, and still produce a template. Warm colours on cold structures. Friendly fonts on generic layouts. A kitchen feel can still look like every other app.
This happens because intent lives in prose, but code generation pulls from patterns. The gap between them is where defaults win.
The process below helps. But process alone doesn't guarantee craft. Defaults must be caught early.
Defaults don't announce themselves. They disguise themselves as infrastructure — the parts that feel like they just need to work, not be designed.
Typography feels like a container. Pick something readable, move on. But typography isn't holding the design — it IS the design. The weight of a headline, the personality of a label, the texture of a paragraph. These shape how the product feels before anyone reads a word. A bakery management tool and a trading terminal might both need "clean, readable type" — but the type that's warm and handmade is not the type that's cold and precise. If the default choice reaches for the usual font, design has defaulted.
Navigation feels like scaffolding. Build the sidebar, add the links, get to the real work. But navigation isn't around the product — it IS the product. Current location, possible destinations, what matters most. A page floating in space is a component demo, not software. The navigation teaches people how to think about the space they're in.
Data feels like presentation. Raw numbers are available, so numbers are displayed. But a number on screen is not design. The question is: what does this number mean to the person looking at it? What will they do with it? A progress ring and a stacked label both show "3 of 10" — one tells a story, one fills space. If the default choice reaches for number-on-label, design has defaulted.
Token names feel like implementation detail. But the Cascading Style Sheets
(CSS) variables are design decisions. --ink and --parchment evoke a world.
--grey-700 and --surface-2 evoke a template. Someone reading only the
tokens should be able to guess what product this is.
The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design. The moment "why this?" stops being asked is the moment defaults take over.
Before touching code, answer these explicitly for the requester.
Who is this human? Not "users." The actual person. Where are they when the interface opens? What is on their mind? What happened 5 minutes ago, and what action follows 5 minutes after? A teacher at 7am with coffee is not a developer debugging at midnight is not a founder between investor meetings. Their world shapes the interface.
What must they accomplish? Not "use the dashboard." The verb. Grade these submissions. Find the broken deployment. Approve the payment. The answer determines what leads, what follows, what hides.
What should this feel like? Say it in words that mean something. "Clean and modern" means nothing — every artificial intelligence (AI) system says that. Warm like a notebook? Cold like a terminal? Dense like a trading floor? Calm like a reading app? The answer shapes colour, type, spacing, density — everything.
If the answers cannot be specific, stop. Ask the requester. Do not guess. Do not default.
For every decision, the designer must be able to explain WHY.
If the answer is "it's common" or "it's clean" or "it works" — no choice has been made. Defaulting has happened. Defaults are invisible. Invisible choices compound into generic output.
The test: If the chosen details were swapped for the most common alternatives and the design didn't feel meaningfully different, real choices were never made.
If another AI, given a similar prompt, would produce substantially the same output — the result has failed.
This is not about being different for its own sake. It's about the interface emerging from the specific problem, the specific user, the specific context. When design proceeds from intent, sameness becomes impossible because no two intents are identical.
When design proceeds from defaults, everything looks the same because defaults are shared.
Saying "warm" and using cold colours is not following through. Intent is not a label — it's a constraint that shapes every decision.
If the intent is warm: surfaces, text, borders, accents, semantic colours, typography — all warm. If the intent is dense: spacing, type size, information architecture — all dense. If the intent is calm: motion, contrast, colour saturation — all calm.
Check the output against the stated intent. Does every token reinforce it? Or was an intent stated before defaulting anyway?
This is where defaults get caught — or don't.
Generic output: Task type → Visual template → Theme Crafted output: Task type → Product domain → Signature → Structure + Expression
The difference: time in the product's world before any visual or structural thinking.
Do not propose any direction until the process produces all four:
Domain: Concepts, metaphors, vocabulary from this product's world. Not features — territory. Minimum 5.
Colour world: What colours exist naturally in this product's domain? Not "warm" or "cool" — go to the actual world. If this product were a physical space, what would be visible? What colours belong there that don't belong elsewhere? List 5+.
Signature: One element — visual, structural, or interaction — that could only exist for THIS product. If one cannot be named, keep exploring.
Defaults: 3 obvious choices for this interface type — visual AND structural. Patterns cannot be avoided until they have been named.
The direction must explicitly reference:
The test: Read the proposal. Remove the product name. Could a reviewer identify what this is for? If not, it's generic. Explore deeper.
Before showing the requester, review the output.
Ask: "If the requester said this lacks craft, what would that mean?"
That critique — fix it first.
The first output is probably generic. That's normal. The work is catching it before the requester has to.
Run these against the output before presenting:
The swap test: If the typeface were swapped for the usual one, would anyone notice? If the layout were swapped for a standard dashboard template, would it feel different? The places where swapping would not matter are the places where defaulting occurred.
The squint test: Blur the view. Can the structure and hierarchy still be perceived? Is anything jumping out harshly? Craft whispers.
The signature test: Can the reviewer point to five specific elements where the signature appears? Not "the overall feel" — actual components. A signature that cannot be located doesn't exist.
The token test: Read the CSS variables out loud. Do those variables sound like they belong to this product's world, or could they belong to any project?
If any check fails, iterate before showing.
This is the backbone of craft. Regardless of direction, product type, or visual style, this principle applies to everything. The system should be barely noticeable when it is working. When looking at Vercel's dashboard, the viewer does not think "nice borders." The structure is understood. The craft is invisible; that is how craft signals that it is working.
Surfaces stack. A dropdown sits above a card which sits above the page. Build a numbered system — base, then increasing elevation levels. In dark mode, higher elevation = slightly lighter. In light mode, higher elevation is slightly lighter or uses shadow.
Each jump should be only a few percentage points of lightness. The difference is barely visible in isolation. But when surfaces stack, the hierarchy emerges. Whisper-quiet shifts are felt rather than seen.
Key decisions:
Borders should disappear when attention is elsewhere, but be findable when structure is needed. Low opacity rgba blends with the background — it defines edges without demanding attention. Solid hex borders look harsh in comparison.
Build a progression — not all borders are equal. Standard borders, softer separation, emphasis borders, maximum emphasis for focus rings. Match intensity to the importance of the boundary.
The squint test: Blur the view at the interface. Hierarchy should remain perceptible — what's above what, where sections divide. But nothing should jump out. No harsh lines. No jarring colour shifts. Just quiet structure.
This separates professional interfaces from amateur ones. Get this wrong and nothing else matters.
Every pattern has infinite expressions. No interface should look the same.
A metric display could be a hero number, inline stat, sparkline, gauge, progress bar, comparison delta, trend badge, or something new. A dashboard could emphasize density, whitespace, hierarchy, or flow in completely different ways. Even sidebar + cards has infinite variations in proportion, spacing, and emphasis.
Before building, answer:
NEVER produce identical output. Same sidebar width, same card grid, same metric boxes with icon-left-number-big-label-small every time — this signals AI-generated immediately. It's forgettable.
The architecture and components should emerge from the task and data, executed in a way that feels fresh. Linear's cards don't look like Notion's. Vercel's metrics don't look like Stripe's. Same concepts, infinite expressions.
Every product exists in a world. That world has colours.
Before reaching for a palette, spend time in the product's world. What would be visible in the physical version of this space? What materials? What light? What objects?
The palette should feel like it came FROM somewhere — not like it was applied TO something.
Beyond Warm and Cold: Temperature is one axis. Is this quiet or loud? Dense or spacious? Serious or playful? Geometric or organic? A trading terminal and a meditation app are both "focused" — completely different kinds of focus. Find the specific quality, not the generic label.
Colour Carries Meaning: Grey builds structure. Colour communicates — status, action, emphasis, identity. Unmotivated colour is noise. One accent colour, used with intention, beats five colours used without thought.
Every time user interface (UI) code is written — even small additions — state:
Intent: [who is this human, what must they do, how should it feel]
Palette: [colours from the exploration — and WHY they fit this product's world]
Depth: [borders / shadows / layered — and WHY this fits the intent]
Surfaces: [the elevation scale — and WHY this colour temperature]
Typography: [the typeface — and WHY it fits the intent]
Spacing: [the base unit]
This checkpoint is mandatory. It forces the designer to connect every technical choice back to intent.
If the rationale cannot explain WHY for each choice, defaulting has happened. Stop and think.
Every colour in the interface should trace back to a small set of primitives: foreground (text hierarchy), background (surface elevation), border (separation hierarchy), brand, and semantic (destructive, warning, success). No random hex values — everything maps to primitives.
Don't just have "text" and "grey text." Build four levels — primary, secondary, tertiary, muted. Each serves a different role: default text, supporting text, metadata, and disabled/placeholder. Use all four consistently. If only two are used, the hierarchy is too flat.
Borders aren't binary. Build a scale that matches intensity to importance — standard separation, softer separation, emphasis, maximum emphasis. Not every boundary deserves the same weight.
Form controls have specific needs. Don't reuse surface tokens — create dedicated ones for control backgrounds, control borders, and focus states. This lets designers tune interactive elements independently of layout surfaces.
Pick a base unit and stick to multiples. Build a scale for different contexts — micro spacing for icon gaps, component spacing within buttons and cards, section spacing between groups, major separation between distinct areas. Random values signal no system.
Keep it symmetrical. If one side has a value, others should match unless content naturally requires asymmetry.
Choose ONE approach and commit:
Don't mix approaches.
Sharper feels technical. Rounder feels friendly. Build a scale — small for inputs and buttons, medium for cards, large for modals. Don't mix sharp and soft randomly.
Build distinct levels distinguishable at a glance. Headlines need weight and tight tracking for presence. Body needs comfortable weight for readability. Labels need medium weight that works at smaller sizes. Data needs monospace with tabular number spacing for alignment. Don't rely on size alone — combine size, weight, and letter-spacing.
A metric card doesn't have to look like a plan card, and a plan card doesn't have to look like a settings card. Design each card's internal structure for its specific content — but keep the surface treatment consistent: same border weight, shadow depth, corner radius, padding scale.
Native <select> and <input type="date"> render operating system (OS)-native
elements that cannot be styled. Build custom components — trigger buttons with
positioned dropdowns, calendar popovers, styled state management.
Icons clarify, not decorate — if removing an icon loses no meaning, remove it. Choose one icon set and stick with it. Give standalone icons presence with subtle background containers.
Fast micro-interactions, smooth easing. Larger transitions can be slightly longer. Use deceleration easing. Avoid spring/bounce in professional interfaces.
Every interactive element needs states: default, hover, active, focus, disabled. Data needs states too: loading, empty, error. Missing states feel broken.
Screens need grounding. A data table floating in space feels like a component demo, not a product. Include navigation showing current location in the app, location indicators, and user context. When building sidebars, consider the same background as main content with border separation rather than different colours.
Dark interfaces have different needs. Shadows are less visible on dark backgrounds — lean on borders for definition. Semantic colours (success, warning, error) often need slight desaturation. The hierarchy system still applies, just with inverted values.
Be invisible. Don't announce modes or narrate process.
Never say: "ESTABLISH MODE is active", "Checking system.md…"
Instead: Jump into work. State suggestions with reasoning.
Lead with the exploration and recommendation, then confirm:
"Domain: [5+ concepts from the product's world]
Colour world: [5+ colours that exist in this domain]
Signature: [one element unique to this product]
Rejecting: [default 1] → [alternative], [default 2] → [alternative], [default 3] → [alternative]
Direction: [approach that connects to the above]"
[Ask: "Does that direction feel right?"]
Read .interface-design/system.md and apply. Decisions are made.
After building something, always offer to save:
"Should these patterns be saved for future sessions?"
If yes, write to .interface-design/system.md:
Add patterns when a component is used 2+ times, is reusable across the project, or has specific measurements worth remembering. Don't save one-off components, temporary experiments, or variations better handled with props.
If system.md defines values, check against them: spacing on the defined grid, depth using the declared strategy throughout, colours from the defined palette, documented patterns reused instead of reinvented.
This compounds — each save makes future work faster and more consistent.
For more detail on specific topics:
references/principles.md — Code examples, specific values, dark modereferences/validation.md — Memory management, when to update system.mdreferences/critique.md — Post-build craft critique protocol/interface-design:status — Current system state/interface-design:audit — Check code against system/interface-design:extract — Extract patterns from code/interface-design:critique — Critique the build for craft, then rebuild
what defaultedDiagnose and add "juice" — game feel, feedback, and tactile polish — to games, prototypes, and interactive software. Use this skill whenever the user is building, polishing, prototyping, or reviewing a game (especially action, arcade, platformer, shooter, or rhythm games), or when they ask about game feel, juice, screen shake, hit feedback, particles, easing, tweening, screen pause/hitstop, juicy effects, "making it feel good", or why their prototype feels limp, lifeless, dry, or cheap. Also trigger when reviewing UI prototypes that need tactile response, or when the user mentions Jonasson, Purho, Vlambeer, Nuclear Throne, screen shake, or Steve Swink's "Game Feel" book. Apply even to non-game interactive software when the user wants buttons, transitions, or interactions to feel responsive and satisfying.
Visual strategy, art direction, and design critique for websites. Use this skill whenever the user asks for visual direction, page design strategy, design critique, hierarchy planning, concept exploration, or art direction for any web page or site — including landing pages, service/transactional pages, dashboards, editorial layouts, portfolios, campaign pages, and design-system foundations. Also trigger when the user asks to evaluate an existing web design, generate concept territories, plan visual hierarchy, choose type/colour/image strategy, or review a design for accessibility and communication clarity. This skill produces design rationale, concept directions, hierarchy maps, system strategies, and review notes — not HTML/CSS code. If the user needs implementation, hand off to the frontend-design skill after the design direction is set.
Local-first Ansible testing for roles and modules within collections. Use whenever the user wants to add, run, scaffold, or debug tests for an Ansible collection, role, or module. Triggers include: "test my Ansible role", "add Molecule tests", "run ansible-test", "set up integration tests", "scaffold a test scenario", "run sanity checks", "write unit tests for a module", "test a collection locally". Always prefer this skill over ad hoc shell suggestions when Ansible testing is the subject. The skill covers the full testing stack: Molecule + Podman for roles, ansible-test for modules and collections (sanity, unit, integration). Python 3.12+, collections layout, and Podman are assumed throughout.
Configure and use Biome (biomejs) for TypeScript linting and formatting. Use when setting up Biome in a project, configuring lint rules, migrating from ESLint/Prettier, fixing lint errors, setting up CI pipelines with Biome, or configuring git hooks for code quality. Covers biome.json configuration, file inclusion/exclusion patterns, rule overrides, and integration with build tooling.
Conduct thorough, actionable code reviews that catch real problems without drowning in noise
Generate, modify, or audit `.codescene/code-health-rules.json` files that control CodeScene's code health scan behaviour. Use this skill whenever the user wants to customize CodeScene rule weights, disable specific smells, adjust metric thresholds, scope rules to test vs application code, apply language-specific overrides, or add in-source `@codescene` directives. Also trigger when the user asks why a CodeScene rule is firing, or wants to suppress a smell across a repo or folder subtree.