DaFink UI
A React component library built around one idea: you should own your UI code. Install only what you need, read it, change it, make it yours. No black-box packages hiding what's actually happening.
Why I built this
I built DaFink UI because I wanted frontend development to be easier for myself first. In undergrad I did a lot of UI work, from laying out entire pages to losing hours on individual components, like the time I spent a full hour figuring out how to style a button correctly in both its hover and selected states. That's where my opinions about how things should look and behave came from, and no library I've used since had all of them built in without hours of overrides.
It's also easier for whatever's writing the code alongside me. I think AI is only going to take on a bigger share of frontend work from here, and most component libraries weren't built with that in mind. An agent can't read a compiled npm package to understand how a component actually behaves, and it definitely can't explain why a prop exists.
So instead of a package, DaFink UI ships as source you copy directly into your project, paired with documentation written so an LLM can use it correctly, not just a human skimming a README. The goal is an ecosystem of components with enough context that an LLM can treat them like Lego blocks: pick the right ones, snap them together, and end up with something accessible and good-looking, not just functional.
I built a Claude Skill and an MCP server so an agent gets that context automatically instead of guessing from training data. And because I don't just want to trust that AI-generated UI is accessible, I also shipped CI/CD scripts (the same ones this project uses on itself) that check the output against real requirements: keyboard navigation, contrast, focus states. Something you can actually verify, not just hope for.
The trade-off is the same one it's always been: you take on the source, I take on making sure it's clean, accessible, and documented well enough that you (or whatever you're pairing with) can actually own it.
AI-native
I've seen firsthand how AI tools are getting woven into everyday workflows, and how imperfect they still are. They hallucinate, they forget style decisions between sessions, and if a rule isn't in the prompt, it's unlikely to make it into the product. I designed DaFink UI to be AI-native from the ground up instead of retrofitted after the fact, so every pattern, naming choice, and file structure holds up to an agent trying to understand and extend it, not just a human reading it.
The MCP server and the Claude Skill add that context to your workflow. Connect either to Claude, Cursor, or any MCP-compatible tool and the agent reads your actual component specs before writing any code, not training data from months ago. Each component ships with a spec.mdfile documenting exactly how it should look and behave in every state, hover and focus included, so you don't have to re-explain it every session.
As engineers we're still responsible for the code we push, whether we wrote it or an agent did. That's what the reliability check is for: an audit tool built to run in your CI pipeline that checks the output against real accessibility requirements instead of just trusting good intentions.
Design philosophy
Over the last few years, as a frontend developer (and as a person who uses the internet) I've grown preferences on the details that make a website stand out to me. I didn't pull these from a style guide, they're just what I've noticed I like (and don't like) using other people's websites. These principles shape every component here: how it looks, how it moves, and how it behaves.
Subtle, intentional animations
Animation makes an interface feel alive. I'd rather see a highlight slide into place than snap there instantly. But it can't be everywhere: inject it into every interaction and it stops feeling alive and starts feeling overengineered.
Consistency
Colors and spacing that drift slightly from page to page never feels right. Every value comes from the same set of CSS variables, so the site feels like one continuous experience instead of a collection of one-off pages.
Accessible by default
WCAG AA contrast, keyboard navigation, and screen reader support aren't a pass at the end, they're part of the plan before any code gets written. If a component can't be used with a keyboard alone, it isn't finished.
Functionality and style
A component has to work first, but that's not where it stops. The best details do both jobs at once: a focus ring that's also handsome, a transition that confirms an action and looks good doing it. Function and style aren't in tension, they're the same job.
Features
Components
The building blocks of your interface. The add command copies the source code directly into your repository, ready to edit and make your own.
Blocks
Premade layouts you can drop into a project to ship a feature fast. Swap in your own data and go.
Token-based theming
Every color, radius, and timing value in every component resolves through a CSS custom property. Swap the tokens, change the look. No component modifications required. Dark mode and all six themes (Zinc, Ocean, Ember, Forest, Noir, and Plum) work this way. Bring your own brand by overriding the same tokens.
AI-assisted development
The built-in MCP server and Claude Skill expose every component spec, token, and design pattern as a live resource, and the reliability check checks whatever gets built against real accessibility requirements, not just hallucinated APIs and good intentions.
Quick start
Initialize DaFink UI in your project, then add your first component. The CLI copies the source into components/ui/, installs any npm dependencies, and transitively resolves any other DaFink UI components it depends on.
See the installation guide for full setup instructions.
Open source
DaFink UI is free and open source. The code, the docs, and the CLI are all on GitHub. Use it, fork it, contribute back. It's yours.