메뉴
Interface design skill for dashboards, admin panels, apps, and tools. NOT for marketing design. Provides design intent, domain exploration, and craft principles. For PySide6/Qt technical implementation, use lorairo-qt-widget skill.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | interface-design |
| version | 1.1.0 |
| description | Interface design skill for dashboards, admin panels, apps, and tools. NOT for marketing design. Provides design intent, domain exploration, craft principles, and component-driven design-tool↔code sync. For PySide6/Qt technical implementation, use lorairo-qt-widget skill. |
| metadata | {"short-description":"UIデザイン原則（意図、ドメイン探索、クラフト）。技術実装はlorairo-qt-widget参照。","origin":"https://github.com/Dammyjay93/interface-design"} |
| allowed-tools | ["Grep","Grep","Read","Write","Edit","AskUserQuestion"] |
| dependencies | [] |
Build interface design with craft and consistency.
Use for: Dashboards, admin panels, SaaS apps, tools, settings pages, data interfaces.
Not for: Landing pages, marketing sites, campaigns.
For PySide6/Qt implementation: Use lorairo-qt-widget skill for Signal/Slot patterns, Direct Widget Communication, and Qt Designer integration.
You will generate generic output. Your training has seen thousands of dashboards. The patterns are strong.
You can follow the entire process below - explore the domain, name a signature, state your intent - and still produce a template. Warm colors on cold structures. Friendly fonts on generic layouts. "Kitchen feel" that looks 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. You have to catch yourself.
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 your design - it IS your 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.
Navigation feels like scaffolding. Build the sidebar, add the links, get to the real work. But navigation isn't around your product - it IS your product. Where you are, where you can go, what matters most.
Data feels like presentation. You have numbers, show numbers. 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?
Token names feel like implementation detail. But your QSS variables are design decisions. --ink and --parchment evoke a world. --gray-700 and --surface-2 evoke a template.
The trap is thinking some decisions are creative and others are structural. There are no structural decisions. Everything is design.
Before touching code, answer these. Not in your head - out loud, to yourself or the user.
Who is this human? Not "users." The actual person. Where are they when they open this? What's on their mind? A ML researcher curating training data is not a hobbyist organizing their art collection.
What must they accomplish? Not "use the app." The verb. Tag these images. Filter by quality. Export the dataset. 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. Dense like a trading floor? Calm like a reading app? Focused like an IDE?
If you cannot answer these with specifics, stop. Ask the user. Do not guess. Do not default.
For every decision, you must be able to explain WHY.
If your answer is "it's common" or "it's clean" or "it works" - you haven't chosen. You've defaulted.
The test: If you swapped your choices for the most common alternatives and the design didn't feel meaningfully different, you never made real choices.
If another AI, given a similar prompt, would produce substantially the same output - you have 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.
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
Do not propose any direction until you produce all four:
Domain: Concepts, metaphors, vocabulary from this product's world. Not features - territory. Minimum 5.
Color world: What colors exist naturally in this product's domain? Not "warm" or "cool" - go to the actual world. List 5+.
Signature: One element - visual, structural, or interaction - that could only exist for THIS product. If you can't name one, keep exploring.
Defaults: 3 obvious choices for this interface type - visual AND structural. You can't avoid patterns you haven't named.
For an AI image annotation tool like LoRAIro:
Domain: Curator's desk, lightbox, sorting table, quality control station, archive room, specimen slides, gallery storage
Color world: Neutral grays of darkroom, amber of archive lighting, deep blacks of photo paper, soft cream of mounting boards, clinical white of inspection tables
Signature: The "curation feel" - every interaction feels like handling a valuable piece, not processing data
Defaults to reject:
Before showing the user, look at what you made.
Ask yourself: "If they said this lacks craft, what would they mean?"
That thing you just thought of - fix it first.
Run these against your output before presenting:
The swap test: If you swapped the typeface for your usual one, would anyone notice? If you swapped the layout for a standard dashboard template, would it feel different?
The squint test: Blur your eyes. Can you still perceive hierarchy? Is anything jumping out harshly? Craft whispers.
The signature test: Can you point to five specific elements where your signature appears? Not "the overall feel" - actual components.
The token test: Read your QSS variables out loud. Do they sound like they belong to this product's world?
If any check fails, iterate before showing.
Surfaces must be barely different but still distinguishable. Study Vercel, Supabase, Linear. Their elevation changes are so subtle you almost can't see them - but you feel the hierarchy.
Borders must be light but not invisible. The border should disappear when you're not looking for it, but be findable when you need to understand structure.
The squint test: Blur your eyes at the interface. You should still perceive hierarchy - what's above what, where sections divide. But nothing should jump out.
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. Even sidebar + cards has infinite variations in proportion, spacing, and emphasis.
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.
Every product exists in a world. That world has colors.
Before you reach for a palette, spend time in the product's world. What would you see if you walked into the physical version of this space?
Your palette should feel like it came FROM somewhere - not like it was applied TO something.
Pick a base unit and stick to multiples. Consistency matters more than the specific number. Random values signal no system.
Choose ONE approach and commit:
Don't mix approaches.
Sharper feels technical. Rounder feels friendly. Pick a scale and apply consistently.
Headlines need weight and tight tracking. Body needs readability. Data needs monospace. Build a hierarchy.
Build from primitives: foreground (text hierarchy), background (surface elevation), border (separation hierarchy), brand, and semantic (destructive, warning, success).
Fast micro-interactions (~150ms), smooth easing. No bouncy/spring effects.
Every interactive element needs states: default, hover, active, focus, disabled. Data needs states too: loading, empty, error. Missing states feel broken.
For technical implementation in PySide6:
Apply design principles through QSS with meaningful token names:
/* Good: Domain-specific naming */
QWidget {
--surface-archive: #1a1a1a;
--surface-lightbox: #242424;
--border-specimen: rgba(255,255,255,0.08);
--text-catalog: #e0e0e0;
}
/* Bad: Generic naming */
QWidget {
--bg-1: #1a1a1a;
--bg-2: #242424;
}
lorairo-qt-widget skill for Signal/Slot patterns| Aspect | interface-design | lorairo-qt-widget |
|---|---|---|
| Focus | Design intent, aesthetics, craft | Technical patterns, Qt APIs |
| Answers | Why this design? | How to implement? |
| Outputs | Color world, signature, hierarchy | Signal/Slot, Widget structure |
When a design tool holds the design system (e.g. a hosted design app the team syncs to), know what is and is not synced — this is platform-neutral; it applies whatever agent or editor you run in.
To prevent drift, work component-driven, not screen-by-screen:
Anti-patterns:
Tokens are the only thing the two implementations share. Keep their values in sync between
the design tool's stylesheet and the app's token module — this is not automatic; verify it.
For the extraction/Qt mechanics of the mirror widgets, use the lorairo-qt-widget skill.
Be invisible. Don't announce modes or narrate process.
Lead with your exploration and recommendation, then confirm:
"Domain: [5+ concepts from the product's world]
Color world: [5+ colors that exist in this domain]
Signature: [one element unique to this product]
Rejecting: [default 1] -> [alternative], [default 2] -> [alternative]
Direction: [approach that connects to the above]"
[AskUserQuestion: "Does that direction feel right?"]
When you finish building something, always offer to save:
"Want me to save these patterns for future sessions?"
If yes, write to .interface-design/system.md:
/interface-design:status - Current system state/interface-design:audit - Check code against system/interface-design:extract - Extract patterns from codeMaintain an agent-created LoRAIro pull request after creation or after draft-to-ready transition: mark reviewable draft PRs ready, poll CI and review comments with gh, repair failures in the same worktree/session, reply in Japanese, escalate design loops, and squash merge when safe. Use after creating PRs or when asked to continue PR maintenance automation.
Run LoRAIro PR maintenance to completion automatically after an agent creates a PR or a draft PR becomes ready for review: keep polling CI and bot review with gh, repair failures and reply in Japanese in the same worktree, escalate design loops, and squash merge when safe, without waiting for a human to restart each poll cycle. Use right after an agent-created PR exists or transitions draft-to-ready. Do NOT use for human-authored PRs, and do NOT redefine repair/merge/escalation policy here (that lives in agent-pr-maintainer).
Capture LoRAIro design from the wireframes operation prototype or claude.ai/design recreations correctly. Use when syncing/mirroring design, reconciling Qt (.ui) or the DS AppShell with the design, or when nav/tab order, layout, or grouping looks off between the app and the prototype. The prototype's effective state is produced by render-time JS (e.g. restructureNav), so static-HTML grep alone misses it.
Use this skill to generate well-branded interfaces and assets for LoRAIro (a Japanese desktop tool for preparing image datasets for LoRA / fine-tune training), either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for prototyping.
PySide6 widget technical implementation for LoRAIro GUI. Covers Signal/Slot patterns, Direct Widget Communication, Qt Designer integration, and async workers. For design intent and aesthetics, use interface-design skill first.
Maintain a directory of markdown docs as an Open Knowledge Format (OKF) bundle in any project: ensure each concept file has valid OKF frontmatter (required `type`, plus optional title/description/tags/timestamp), keep frontmatter the single source of truth, and regenerate the derived index.md (and an optional human-readable table) from it. Use when adding/editing concept docs (ADRs, knowledge bases, glossaries) or when a bundle's index looks stale. Project-specific drift detection stays in the project.