Hello DEV community! 👋 For my first post, I want to share why I started building Coordiation CSS, an independent utility first CSS compiler focused on static output, owned source, and machine readable contracts. Coordiation is currently at version 1.0.0-rc.1. This is a release candidate, not a claim that the project is finished. I am sharing it now because early technical feedback is more useful than waiting until everything feels perfect. The problem I wanted to explore Modern frontend teams need more than a collection of short class names. They need a system that stays understandable as an application grows. Humans need predictable utilities, accessible components, and documentation that explains the real behavior of the system. AI coding agents need many of the same things, but in a more explicit form. They need exact names, finite choices, version information, warnings, and contracts that can be inspected without guessing. That led me to a simple question: What would a CSS framework look like if its source of truth worked equally well for people, build tools, editors, and AI agents? Coordiation is my attempt to explore that question. Static CSS without a browser runtime Coordiation scans templates for literal co- utility candidates and generates static CSS during development or at build time. A button can be written like this: <button class="co-rounded-lg co-bg-brand-500 co-px-4 co-py-2 co-text-white hover:co-bg-brand-600"> Save changes </button> The application receives ordinary CSS. It does not need a client side styling runtime to interpret those classes in the browser. For a Vite project, the release candidate can be installed with: npm install -D @coordiation/css@next @coordiation/vite@next vite Then the Vite integration can scan the project and serve the generated stylesheet: import { defineConfig } from "vite"; import coordiation from "@coordiation/vite"; export default defineConfig({ plugins: [coordiation({ content: ["src"] })] }); The CSS entry begins with: @coordiation; The goal is a short authoring loop with output that remains standards based and inspectable. Why machine readable registries matter Documentation is useful, but prose alone is difficult to keep synchronized with a compiler. Coordiation generates registries for utilities, icons, components, themes, compatibility information, and project context. The same data can support documentation, tests, editor tooling, installers, and AI agents. For example, an agent can inspect the active framework version, supported utility families, component contracts, and warnings before changing an interface. This reduces the need to infer conventions from a few nearby files. I do not think AI needs less context. I think it needs better structured context. Open code instead of hidden component behavior Coordiation currently includes 64 open code React components. The installer copies the selected component source into the application repository. After installation, the component belongs to the project. A team can inspect it, change it, test it, and remove it without depending on a visual builder or a component runtime controlled elsewhere. The same approach is used for 10 complete application themes. They are intended as editable starting points, not locked templates. The icon package currently includes 2,165 glyphs from the Solar Linear and Iconsax Line Oval collections, together with registry metadata and collection specific licensing information. One coordinated toolchain The release candidate contains twelve public packages covering the compiler, Vite and PostCSS integrations, CLI, icons, components, themes, formatter, upgrade tools, language server, optional native scanning, and agent context. One part I care about deeply is synchronization. If documentation says a utility exists, the registry and test suite should be able to prove it. If a compatibility claim cannot be verified, it should remain a roadmap item instead of becoming marketing copy. Stable version 1.0 is still a target. The current release candidate exists so the package train, platform support, artifacts, and release process can be tested together. What I hope to learn here I joined DEV to share the engineering decisions behind Coordiation, including the decisions that do not work on the first attempt. I would especially value feedback on these questions: Are the co- utilities readable when you first encounter them? Would machine readable registries help your editor or AI assisted workflow? Does copying component source into a project feel clearer than importing a closed component package? Which part of the installation or documentation creates the most friction? You can explore the project here: Website and documentation: coordiation.com Source code: github.com/wiryosaputraofficial/coordiationcss Thanks for reading. I am looking forward to learning from the DEV community and hearing how other developers approach CSS systems, component ownership, and AI assisted frontend work. Disclosure: I used AI assistance to help organize and edit the language of this article. I reviewed the technical claims and examples against the Coordiation source code and documentation.