메뉴
Build or redesign frontend UI that doesn't look templated or AI-generated. Use when creating components, pages, landing pages, or restyling existing UI — before writing CSS/markup, and before shipping any visual work.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Query forge's live, always-fresh code map — a dependency graph of the repo with god-nodes, modules, and neighbors/impact (blast-radius) queries. Use before editing to know what depends on a file, to find the most-depended-on hotspots, to map an unfamiliar codebase's architecture, or whenever you need current structural context instead of guessing.
Build an accurate mental map of unfamiliar code before changing it. Use when starting work in a codebase or area you don't know well, before editing code whose ripple effects you can't predict, or when the user asks how something works or where something lives.
Design the shape of a non-trivial module, API, or system before implementing it. Use when a design decision has more than one reasonable answer, when introducing a new abstraction or interface, or when getting the shape wrong would be expensive to undo.
Turn a vague idea into an approved, written spec before any code is written. Use before building a feature, adding functionality, or changing behavior — whenever the work is more than a trivial mechanical edit and the requirements aren't already pinned down.
Find the root cause of a bug, test failure, or performance regression before proposing any fix. Use the moment something is broken, throwing, failing, flaky, or slower than expected — and resist the urge to patch first.
Measure non-deterministic behavior — LLM features, agents, prompts, or a skill itself — with repeatable evals instead of one-shot checks. Use when building or tuning AI/LLM functionality (ranking, extraction, generation, agent loops), when a feature could pass once by luck, or when validating that a prompt or skill actually changes behavior.
| name | design-ui |
| description | Build or redesign frontend UI that doesn't look templated or AI-generated. Use when creating components, pages, landing pages, or restyling existing UI — before writing CSS/markup, and before shipping any visual work. |
██████╗ ███████╗███████╗██╗ ██████╗ ███╗ ██╗ ██╗ ██╗██╗
██╔══██╗██╔════╝██╔════╝██║██╔════╝ ████╗ ██║ ██║ ██║██║
██║ ██║█████╗ ███████╗██║██║ ███╗██╔██╗ ██║█████╗██║ ██║██║
██║ ██║██╔══╝ ╚════██║██║██║ ██║██║╚██╗██║╚════╝██║ ██║██║
██████╔╝███████╗███████║██║╚██████╔╝██║ ╚████║ ╚██████╔╝██║
╚═════╝ ╚══════╝╚══════╝╚═╝ ╚═════╝ ╚═╝ ╚═══╝ ╚═════╝ ╚═╝
Default AI design fails because it reaches for statistical clichés. This skill replaces "looks fine" with deliberate, checkable taste. The premise: bad AI UI is predictable, so the fixes can be mechanical.
Before any markup, state one line: "Reading this as a <page kind> for <audience>, vibe <word>, leaning <direction>." Then set three dials (1-10) and let them drive choices:
The dials are constraints, not decoration — let the value gate the technique: MOTION_INTENSITY ≤ 3 → no scroll-jacking/parallax, hover/focus only; VISUAL_DENSITY ≤ 3 → generous whitespace, one primary action per view. If a choice violates its dial, change the choice.
Pick a single aesthetic and execute it fully — minimalist editorial (Notion/Linear), high-end agency, brutalist/industrial, etc. Averaging directions produces mush. If the user hasn't chosen, propose one with rationale.
These are the AI tells; treat them as hard checks, not suggestions:
#8B5CF6-family default gradients.shadow-md-equivalent); no default linear/ease-in-out timing. Use intentional borders, layered/soft shadows, and ≥1 custom easing or spring. (Tailwind names are just examples — the rule is the rendered property, so it applies equally on vanilla CSS, styled-components, SwiftUI, etc.)Render the real view (dev-preview harness + headless browser / Playwright with system Chrome), then re-read the screenshots — don't infer from CSS. Make it a mechanical gate: capture at 390 / 768 / 1280 px widths, save to a scratch dir, and forbid "done" unless those files exist and you've inspected them for spacing, hierarchy, contrast, overflow, and small-screen fit. A screenshot you never open is not verification. (This is forge:verify applied to pixels.)
Before "done," tick: direction committed · type deliberate · spacing rhythm consistent · hierarchy clear · states (hover/focus/empty/error) handled · responsive checked · text contrast ≥ 4.5:1 (WCAG AA) on the rendered output · visible focus ring on every interactive element · all motion gated behind prefers-reduced-motion: no-preference · all bans above honestly clear · rendered-and-eyeballed. If any box can't be honestly ticked, it isn't finished.
For reference-image-first workflows (generate comps, then build to match), the tasteskill:imagegen-* and tasteskill:image-to-code skills complement this — this skill is the code-side taste enforcer.