cito is the prefix I use for things I want to keep around as a reference for myself: organising design tokens, UI patterns, small utilities, templates and experiments. It is not a open source project and it is not trying to become a universal design system. It is a name for a practical collection of decisions that help me get from an empty project to a usable interface with least amount of work.
"Cito" has gradually become a useful tool for framing. Anything "Cito" should be safe to copy into another project, easy to inspect, and useful enough that I will remember to reach for it next time.
The most visible part is cito.css, a CSS foundation and component starting point. It also includes working reference book around the CSS: the theme controller, the component examples, the patterns, and the notes about why the pieces are arranged the way they are. That is the ambitious goal at least.
Most projects do not need a design system. As a design system enthusiast, I have learned that they can become one of the biggest speed bumps when it comes to moving work forward and getting things done. Projects need a sensible beginning and a continuous reference, not a bureaucratic meta-layer that aims to solve everything without a real mandate or budget.
Instead of alignment meetings and sync reviews, a project needs typography that does not need to be reconsidered on the first screen, consistent spacing, colours with a useful semantic scheme, accessible focus states, and forms and buttons that are simple to use rather than overly decorated or unnecessarily fancy. It also needs a way to support a second theme when appropriate. I believe every app should have at least two themes from the start: light and dark. That's it.
Cito's CSS custom properties form a private palette underneath a public semantic API. Application code uses names such as --cito-text-*, --cito-ui-*, and --cito-primary-*, rather than reaching into raw colour values. A theme can then map those semantic names differently without requiring every component to be rewritten. It is rather simple system, but it has proven itself to be effetive and easy to reason about.
This is not a new idea. Variables and semantic organisation have been standard advice for a long time. The useful part is having the arrangement already made, tested in ordinary work, and available when I need it. As a long-time Bootstrap user I value the fact that things work, but with Cito I also understand why they work and I get to design them as minimal as possible. Of course, Cito is nowhere close to the scope of Bootstrap, but it still gives styles a small grammar. Instead of deciding how every new element should look, I can decide what role it has in the interface and work from there. The purpose is not to overly-complicate things either.
The same idea applies to theming. The accompanying theme controller is deliberately small: it reads the system preference and stored choice, sets a data-theme attribute on the root element, and lets CSS do the rest. Projects that do not need a manual switch can omit the JavaScript and use prefers-color-scheme alone. The baseline is standard CSS and browser behaviour, not a framework-specific mechanism.
Cito starter setups has gone many variations. I have created a full-stack Node.js template that would provide one complete starting arrangement. In theory it promised a fast route into a new application. In practice it demanded too much configuration and maintenance. The template became the project. Keeping its dependencies, build decisions and conventions current took attention away from the original purpose: making design and development quicker. The idea of Cito was about the speed of iterations, way before the AI made prototyping even easier.
That attempt clarified the boundary. Cito should reduce decisions, not create a second platform that needs its own roadmap. It works better as a collection of stable, standard-based pieces than as an opinionated application generator.
The frontend layer has changed several times along the way. I have used plain HTML and JavaScript, React, Angular, and smaller experiments between them. Each choice taught me something, but the CSS has stayed deliberately portable. It can be loaded in any setup that follows normal web conventions; the framework only needs to give the styles an appropriate scope.
The current frontend reference uses Angular. This is not an argument that Angular is the only sensible choice, or that it is inherently better than React, Vue, Svelte or any other setup. It is the option that currently gives me a robust frame with fewer recurring decisions.
Angular provides conventions for application structure, routing, components, forms and builds. Those conventions can feel restrictive when a project needs to be unusual. For a reference setup, though, they are valuable precisely because they make the common decisions once. I can put energy into the interaction and the visual language instead of repeatedly assembling the same scaffolding and reviewing dependencies.
The latest Angular port was also a useful AI-assisted exercise. With a clear target and the existing Cito material as reference based on vanilla Typescript and HTML, I rebuilt the setup in a day using Claude Opus 4.8. As Claude was busy converting the examples I was configuring the Angular project itself. That speed did not come from asking a model to invent a design system. It came from having known source material, clear conventions, and a concrete result to compare against. The model was effective because there was already something coherent to preserve.
It might seem that templates become unnecessary when an AI can generate a UI from a short description. I think the opposite is closer to the truth. Templates, patterns and working examples are more useful when they can be handed to a model as grounded context.
The model can produce a lot of plausible code, but it does not remove the need to understand the wiring. Someone still needs to know where styles belong, how a theme is applied, which variables are public, and how the pieces should behave when the first generated result is slightly wrong. The difficult work tends to live in those details: the awkward responsive state, the contrast problem in the dark theme, the component that does not quite work as expected.
A template I know well gives me a faster way to find those problems. It is also easy to skin for another project. A modest set of tokens, typography choices, and component rules can change an application's character quickly. AI can help make those changes, but familiarity with the template is what makes the inevitable corrections cheap and fast.
There is an ergonomic reason too. Reusing known patterns reduces the amount of context I have to reconstruct. I do not need to explain a whole styling strategy every time I start a session. I can point at the reference, say what should differ, and concentrate on the work that is actually new.
I now think of Cito less as a system to finish and more as a learning diary. That becomes more valuable as local language models improve. A robust, explicit setup is good context for a model, as it is for the human. Cito will probably continue to change in small increments: better examples, clearer documentation, a few more patterns, and adjustments that make its relationship with AI-assisted work more useful. I am not looking to make it larger for its own sake. The point is still the same as it was at the beginning: keep the useful decisions nearby, so the next piece of design and development can start with a little more confidence and a little less setup.