th-design

name	th-design
description	Use for UI/UX design work on anything with a user surface — web UI, TUI, CLI ergonomics, dashboards, internal tools — holding a design, spec, mockup, or implementation to the owner's design bar, or building/styling distinctive production-grade frontends. The bar: seamless snappy UX, accessible consistent visuals, calibrated density, discoverable features with shortcut surfaces (command palettes), perceived-performance engineering, motion restraint; chart construction (dataviz) executes under it. Triggers: "design this UI", "build/style this page or component", "review this UX", "walk through the UX", "is this too dense/sparse", "make this feel faster", "add a command palette", "audit accessibility", "pick colors", "set up a design system", "make this look less generic".
metadata	{"owner":"tze","authors":["tze","Claude Fable 5","OpenAI Codex"],"status":"active","last_reviewed":"2026-07-19"}

TH Design

Superskill router for the owner's design bar. Seven subskills live under subskills/, each a complete skill package. Not in the global catalog — discover lazily, load at most one subskill body per subdomain, and fan out subagents only when scope warrants (see "Subagent dispatch").

The thesis: seamless UX. The interface moves as fast as the user's thought, shows what matters without dilution, and never makes them hunt, wait, or re-read. This bar applies to anything a human uses — a button, a CLI flag, a config file, an error message — not just web frontends.

/th-engineering governs how the code is built; this superskill governs how the product feels. Execution craft lives in the frontend-design subskill (greenfield builds and styling), the external impeccable package (see "External craft skills"), and /dataviz (charts); when any of them conflicts with this bar, this bar wins.

Routing table

Task intent	Subskill	Typical trigger
Holistic design bar: default biases, the UX walkthrough ritual, definition of done for any user-facing change.	subskills/design-bar/SKILL.md	"hold this to the design bar", "walk through the UX", "is this UX done"
Information density, hierarchy, succinct copy, layout organization, forms and validation timing: what a surface says and in what order.	subskills/information-design/SKILL.md	"is this too dense/sparse", "organize this screen", "tighten this copy"
Color semantics, visual consistency, typography/spacing scales, motion restraint; establishing a project design system (tokens, meanings, design-language spec).	subskills/visual-language/SKILL.md	"pick colors", "is this consistent", "is this animation necessary", "set up a design system"
Perceived performance: latency budgets, preloading, caching, optimistic rendering, idempotent controls, interruption and toast policy.	subskills/interaction-speed/SKILL.md	"make this feel faster", "feels sluggish", "users double-click this"
Feature discoverability and shortcut surfaces: command palettes, keyboard paths, CLI help/completions, contextual controls, empty states that teach.	subskills/discoverability/SKILL.md	"add a command palette", "nobody finds this feature", "keyboard-first"
Accessibility: keyboard operability, focus, contrast, semantics, reduced motion.	subskills/accessibility/SKILL.md	"audit accessibility", "contrast check", "screen reader support"
Execution: build or restyle distinctive production-grade web UI (pages, components, artifacts) with a committed aesthetic direction, avoiding generic-AI looks. Output obeys the bar subskills above.	subskills/frontend-design/SKILL.md	"build this page/component", "style/beautify this UI", "make this look less generic"

Routing rules

• Bar vs. subdomain: holistic "is this good/designed right" → design-bar; an ask naming one subdomain → that subskill directly.
• Feel vs. build: how the product should behave and look → here. Code quality of the implementation → /th-engineering. Chart palette and mark construction → /dataviz, under this bar's biases; a chart hue that contradicts the app's color semantics is a visual-language finding.
• Doctrine vs. execution: bar subskills decide what "good" means; execution craft produces it. Web build/styling asks → the frontend-design subskill; deep iterative polish of an existing frontend in a project wired for it → external impeccable (below). On conflict, design-bar's biases win.
• Speed symptoms vs. perf bugs: "feels slow/janky" → interaction-speed first; it sets the behavioral bar. Escalate to /th-engineering diagnosis only once a previously met bar has demonstrably regressed and the cause is unknown.
• Fallback: design-adjacent but no row fits → answer from router-level context or ask; don't load a subskill to browse.

Discover subskills

The routing table above is the primary index — route from it directly. Run this only when the table seems stale or you need to verify subskill frontmatter:

PKG="$(dirname "<absolute-path-to-this-SKILL.md>")"
find "$PKG/subskills" -maxdepth 2 -name SKILL.md
rg -n "^name:|^description:" "$PKG"/subskills/*/SKILL.md

Resolve PKG from the base directory your skill loader reported when it loaded this file; never assume the current working directory is the package.

External craft skills

impeccable (upstream: pbakaus/impeccable) is deliberately kept outside every scanned skills directory — its broad triggers would collide with this router's in the catalog. Load it by path when a project needs its deep iterative frontend-polish workflow:

~/.agents/vendor/impeccable/SKILL.md

Caveats: it expects a project-side .agents/skills/impeccable/ install (its context loader runs node .agents/skills/impeccable/scripts/load-context.mjs from the project root) and PRODUCT.md/DESIGN.md conventions. If the target project lacks that wiring, prefer the frontend-design subskill instead of fighting impeccable's gates. Its output remains subject to this bar.

Subagent dispatch

Subskills are independent subdomains; multi-subdomain work parallelizes — but scale dispatch to scope:

• Small scope, several subdomains (one screen, one flow, one CLI): run design-bar's walkthrough inline and consult subdomain expectations directly; no fan-out.
• Design review sweep (multi-screen/multi-flow scope AND ≥3 subdomains): one subagent per relevant subskill. Each prompt carries (1) the absolute path to its subskills/<name>/SKILL.md with instruction to read and apply it, (2) exact scope (screens, components, files, flows), (3) the output contract: findings with evidence (screen/component/file:line) and a proposed fix. Parent synthesizes and dedupes; conflicts resolve via design-bar's biases.
• Iteration-heavy single subdomains (color-palette tuning, command-palette build, density pass on one dashboard): delegate the whole loop, review the returned artifact.
• One narrow question: load the single subskill, answer directly.

Shared invariants (all subskills)

• subskills/design-bar/SKILL.md owns the baseline every subskill assumes — the default biases, evidence-cited findings, severity rule, and fix-it-now policy. A project's own design system overrides individual biases where present; absence of one never lowers the bar. Design-bar also owns the locate step: find the project's design system (design-language specs, doctrine docs, token files) before reviewing, and cite it over generic biases. Some projects keep the design language as a normative spec (e.g. openspec/specs/*design-language*/) — changes to the language then go through the spec workflow, not ad-hoc edits.
• Expectations apply to specs and mockups as much as built UI.
• Small in-scope findings fix now; consent/auth, trust-boundary, contract, or genuinely new behavior discoveries return to /th-projects at the earliest affected spec gate. Full finding classification lives in design-bar.
• Subskills reference each other by relative path (../design-bar/…); those paths are package-internal and stable.