A reverse dictionary for design and UI work. The goal is to go from a fuzzy description of a concept to the precise, agreed-upon word — and to know the difference between words that look interchangeable but aren't. These are the terms from index.how/to/articulate: "the words designers use when they know what they're looking at." The authoritative list of terms and definitions is bundled next to this file: Always pull the exact definition from there — it is the canonical…
Thirty-two portable CSS transitions, each namespaced under t-* selectors with semantic CSS custom properties. Drop-in: paste the snippet, wire the documented HTML hooks, done. No framework dependencies, no demo-specific markup, and every snippet ships a prefers-reduced-motion guard.
An add-on to the transitions-dev skill. Where transitions-dev installs whole transitions, this skill polishes motion that already exists: it scans the five motion-token dimensions — duration, distance, scale, blur, easing — and suggests the token each value should reference, plus the higher-order rules for when a value is right (open/close asymmetry, hover in/out, stagger, delay). Install it alongside transitions-dev, or on its own — the token values are restated below so this skill can audit a project standalone. When it…
Most accessibility is free if you use the platform. Native elements ship with keyboard support, real labels announce themselves and a visible focus ring is one CSS rule. Write every fix in the project's styling system, and use the exact values below rather than familiar-looking substitutes. Reviewing means two walks. Keyboard-only, where every flow completes without a mouse. Then screen-reader, where every control announces a name, a role and its state. When unsure, take the platform default over a custom…
A color system is a small set of ramps, named by role and verified against the backgrounds they actually render on. Most color bugs are system bugs. A value picked in isolation, a token borrowed because it looked right, a pair nobody measured. Never report a contrast value you did not measure, and never estimate a color you could compute. Colors are one of the few interface concerns with an exact answer, so produce the exact answer. Contrast requirements belong…
This skill runs a cross-discipline review. It routes the interface to each better-* skill, collects their evidence and consolidates one ranked verdict. Orchestration is all it owns. Accessibility rules belong to better-accessibility, structure to better-layout, copy to better-writing, type to better-typography, color to better-colors, visual polish and motion to better-ui. Never duplicate or override their rules here. Change-scoped review of uncommitted work, branches and pull requests belongs to interface-review, which resolves the scope and classifies findings before handing the review…
Position, spacing and alignment carry hierarchy before a word is read. This skill builds that structure and stress-tests it: resize it, translate it, mirror it for RTL. Write every fix in the project's styling system. The numbers below are starting points for interfaces with no established density system, and where one applies, use it as written rather than a familiar-looking substitute. Keep deliberate platform chrome, compact professional tools and project tokens where they still pass the stress tests. Hit areas…
Typography is mostly restraint: a sensible scale, comfortable spacing, enough contrast. A label, a table cell, a marketing headline and an article paragraph do not share one set of rules. When reviewing, read the rendered page instead of scanning the code. Bad wrapping, widows and truncation only show up at real content lengths. Write every fix in the project's styling system, and use the exact values below rather than familiar-looking equivalents. The cheat sheet maps each declaration to its Tailwind…
Polish comes from a pile of small details that compound. This skill is the reference for which are worth having and what values they take. When reviewing, slow the interface down. What feels off at 10% speed is what is subtly wrong at full speed. Keep the project's component library, tokens and density, and match its motion language except where a rule below prescribes an exact interaction. Every duration, curve, scale and blur below is a specific value, not a…
Clear and brief beats clever; consistent beats varied. The best error message is the interaction redesigned so the error cannot happen. How copy renders (capitalization via text-transform, truncation, smart punctuation) belongs to better-typography. Error markup and announcements (aria-invalid, live regions) belong to better-accessibility. Room for translated strings belongs to better-layout. Before writing or reviewing, read the copy nearby. Note the product's terminology, its localization conventions and any voice or content style guide. A deliberate brand voice is not a defect.…
This skill takes one component and renders it on a fresh page under every scenario that can actually reach it. That page is the deliverable: a visual report the user scrolls through, every state side by side, with the breaks marked. A component built against one happy path looks finished right up until real content arrives. It observes rather than judges. A finding here is something that visibly broke on the page, named in the vocabulary of the domain skill…
This skill answers how something was built. /explain-interface how the gradient on example.com was built finds the layers producing that gradient and explains what each one contributes. It explains rather than judges. There is no verdict, because how someone else built their interface is not a finding. Reviewing against a standard is interface-review and better-interface; exploring alternatives for your own is variant. Two questions. They share nothing but the evidence rules: Given a named thing, scope to it. A type…
This skill reviews a change rather than a screen. It resolves the scope, expands the changed files to the surfaces they affect, reads both sides of the diff and classifies every finding. Scope is all it owns. Domain rules belong to the better-* skills. Severity, consolidation, coverage, the cap and the verdict belong to better-interface, which this skill hands the review to. Correctness, tests, security and performance belong to the project's general code review. Name the concern once and move…
Great interfaces rarely come from a single thing. It's usually a collection of small details that compound into a great experience. Apply these principles when building or reviewing UI code. Before suggesting or writing a fix, identify the project's existing styling system and express the change in that system: Tailwind in a Tailwind project, plain CSS in a CSS project, or the established CSS-in-JS approach. Never introduce a second styling system just to apply a polish fix. When reviewing, slow…
This skill takes one described piece of UI and builds three versions that differ on purpose. They go behind a picker in the real page, so you can flip between them and choose. Every other skill here judges. This one produces candidates and hands the decision back. Reviewing existing UI is interface-review and better-interface, and it does not pick the winner. Three variants that differ in accent color teach nothing. You flip between them, see no real choice and the…
Surface architectural friction and propose deepening opportunities: refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability. This command is informed by the project's domain model and built on a shared design vocabulary: Scope before you scan: YAGNI. Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide where to look before you look: Read the project's domain glossary…
Scaffold the per-repo configuration that the engineering skills assume: This is a prompt-driven skill, not a deterministic script. Explore, present what you found, confirm with the user, then write. Look at the current repo to understand its starting state. Read whatever exists; don't assume: Summarise what's present and what's missing. Then take the sections in order. One section, one answer, then the next. Lead each section with the recommended answer so the user can accept it in a word. Give…
TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after. When exploring the codebase, read GLOSSARY.md (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching. Tests…
A folder with a SKILL.md file: a name, a description of when to use it, and instructions. Claude loads a skill only when the task matches its description.
How do I use one I find here?
Copy the folder into your project's .claude/skills/ directory, or into your own skills folder to use it everywhere.
What do the warnings mean?
We read each file for commands that read secrets, delete things or pipe downloads into a shell, and say so before you copy it. No warning is not a promise that a file is safe.
Which skills worked for people?
Open a skill to see its discussion. Reports from people and their agents are coming.
sanmidableSkill