jakubkrehel/skills: Agent Skills for UI, Typography and Color Work

The interface details that get skipped when you ship fast

Most review tooling checks what a machine can measure: contrast ratios, missing alt text, bundle size. The details that make an interface feel considered sit outside that net. Concentric border radius on nested elements, optical alignment of an icon against a text baseline, hit areas that are larger than the visible control, type scales where every step is a deliberate ratio rather than a hand-picked number. These are the topics the repository's README lists for better-ui and better-typography, and they are exactly the ones a reviewer skips when a pull request is already three days old.

The intended user is a design engineer or frontend developer who already works with a coding agent and wants that agent to hold an opinion about interface craft. The collection is written in Markdown and lives under a skills/ directory, one folder per skill, each with a SKILL.md file. It is not a library you import and not a service you call. It is a set of instructions the agent reads before it touches your components.

How the skills are structured and what the agent actually receives

Every skill is a directory under skills/ containing a SKILL.md file. The README links each one directly, for example skills/better-ui/SKILL.md and skills/better-colors/SKILL.md. That file is the whole mechanism: front matter that tells the agent when the skill applies, and prose that tells it what to look for. There is no runtime, no parser and no build step in the repository layout. The top-level entries are .claude-plugin/, AGENTS.md, CLAUDE.md, LICENSE, README.md, opencode.json and skills/.

The naming splits into two groups. The better-* skills are topic scoped and can be pulled in when the agent is working on that topic: better-ui, better-typography, better-colors, better-accessibility, better-layout and better-writing. better-interface is described in the README as combining all of the better-* skills into a single review. The second group is explicitly user-invoked, which the README states for each one: interface-review produces a multi-category analysis across UI, typography, layout, color, writing and accessibility; explain-interface helps you work out how an animation or a piece of UI was built on the web; break renders a component in every state and scenario on a temporary page; variant builds multiple variants of a component so you can iterate. The AGENTS.md and CLAUDE.md files at the repository root are the convention files agents read for project-level instructions, and opencode.json points at OpenCode support.

Installing the skills and running a first review

The README gives one install command for the general case. It fetches the collection and registers the skills with your agent tooling.

npx skills add jakubkrehel/skills

There is also a Claude Code plugin path, which the README shows as two slash commands inside the agent rather than as shell commands. The first registers the marketplace, the second installs the plugin named interfaces from the marketplace named interfaces.

/plugin marketplace add jakubkrehel/skills
/plugin install interfaces@interfaces

After either route, the skills are available to the agent. The README marks four of them as user-invoked, so you call them rather than waiting for the agent to decide. A realistic first use is to point the agent at one component you are unhappy with and ask for interface-review, which the README says reviews work across UI, typography, layout, color, writing and accessibility and returns a detailed analysis of the findings. Expect a written list of observations tied to your code, not a patch. If you want the component pushed harder, break renders it in every state and scenario on a temporary page, which is the closest thing here to an executable check.

The repository does not document configuration keys, a config file format or per-skill options. Anything beyond install and invocation is left to the SKILL.md files themselves.

Where this collection stops being useful

The honest limitation is that these are opinions in prose. A skill cannot run your component, measure the rendered gap between two elements, or fail a build. If your team needs enforcement, this is the wrong layer: a skill will tell the agent that a radius looks wrong, and the agent may or may not change the code, and nothing stops a developer from ignoring the result. The break skill is the only one the README describes as producing something rendered, and even that is a temporary page for stress testing, not an assertion suite.

There is a second failure mode that follows from the first. The skills encode specific tastes, drawn from the author's writing on jakub.kr and the Interfaces magazine. If your design system uses a type scale, spacing rhythm or radius convention that differs from the one in better-typography or better-ui, the review will flag correct code as wrong. You then spend time arguing with the agent instead of shipping. Check the SKILL.md files before you install if your system is opinionated.

Finally, the repository has no releases and no version tags in the repository layout. The last push was on 2026-08-29, so the content is current as of that date, but there is no changelog to read when a skill's advice changes under you.

How it differs from a design-token linter or a component library

The obvious comparison is a token linter such as Stylelint with a design-token plugin. That tool parses your CSS, compares values against a configured allowlist and exits non-zero on a violation. It is deterministic and it runs in CI. The trade-off is scope: a linter can tell you that 13px is not in your scale, but it cannot tell you that the icon in a button is optically misaligned or that the copy in an empty state is doing too much work. The skills in this repository target that second category, and they pay for it by giving up determinism. Nothing here will block a merge.

A component library sits at the other end. It removes the decision by shipping a button that is already correct. That works until you need a control the library does not have. The skills assume you are writing the component yourself and want guidance during that writing, which is why the README frames them as things that help you build an interface rather than things that build one for you. The two approaches are complementary: a library sets the baseline, a skill reviews what you add on top.

Maintenance, licence and the cost of keeping up

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. That is a permissive choice and it matters here because the skills are text you may want to fork: editing a SKILL.md to match your own conventions is a normal thing to do, and MIT does not stand in the way. This is not legal advice; read LICENSE for the exact terms.

The upgrade cost is low but not zero. Because the skills are Markdown, an update can change the advice the agent gives without changing any dependency you can see. There is no release history in the repository, so the way to track changes is to diff the skills/ directory between pulls of the repository. If you have forked or edited a SKILL.md, that diff will conflict, and you will need to decide per file whether the upstream wording is better than yours. Budget for that, and consider keeping local edits in a separate file the agent reads after the upstream skill rather than editing the skill in place.

Editorial conclusion

Adopt jakubkrehel/skills if you already drive an agent such as Claude Code or OpenCode on real component code and want a second opinion on spacing, type scale, contrast and copy. Do not adopt it if you expect a build-time linter, a Figma plugin or a tool that fixes anything on its own; every skill is Markdown instructions, so the agent does the work and the skill only directs it. Before installing, open skills/better-ui/SKILL.md and skills/better-typography/SKILL.md and check whether their opinions match your design system, because a skill that disagrees with your tokens will produce review comments you have to reject one by one.

Frequently asked questions

Official sources

1. Issues
2. jakubkrehel/skills on GitHub
3. License: MIT
4. Project website
5. README