design-bar

name	design-bar
description	Use when designing or reviewing anything with a user surface and you need the canonical design quality bar — default UX biases, the UX walkthrough ritual, and the definition of done — or when resolving conflicts between design subdomain findings.
metadata	{"owner":"tze","authors":["tze","Claude Fable 5","OpenAI Codex"],"status":"active","last_reviewed":"2026-07-19"}

Design Bar

Canonical default quality bar for user-facing work. The goal is seamless UX: the interface moves as fast as the user's thought and never makes them hunt, wait, or re-read. Everything here is a reviewable expectation: a reviewer can reject a design or change for violating it. A project's own design system overrides individual biases where present; when a bias is not overridden, it applies.

Use This Skill When

• Designing any feature with a user surface — web UI, TUI, CLI, config file, API ergonomics, error message — and deciding what "good" requires
• Reviewing a design, mockup, or implemented UI holistically before shipping
• Resolving a conflict between subdomain findings (e.g. density vs. accessibility) — biases set the tiebreak

Example trigger phrasings: "hold this to the design bar", "walk through the UX", "is this UX done", "design this feature", "review this flow".

Do Not Use This Skill For

• Deep work in one subdomain — route to the sibling subskill (information-design, visual-language, interaction-speed, discoverability, accessibility)
• Implementation code quality — /th-engineering