agentic-acss-plugins
[!WARNING]
Experimental — This project is under active exploration. APIs, commands, and conventions may change significantly between versions. The core idea — replacing npm packages with agent-driven skills — is still being validated, and we expect the approach to evolve as we learn what works best in practice.
A Claude Code plugin marketplace for building accessible React applications with the fpkit/acss design system. Two decoupled plugins, no npm package to add.
What this is: a marketplace of Claude Code plugins — markdown-as-source skills, slash commands, and Python 3 scripts (mostly stdlib-only; acss-kit/scripts/validate_utilities.py uses tinycss2). There is no Node.js build and no publish pipeline; the only GitHub Actions workflows are Claude-driven review automations under .github/workflows/. Plugins drop generated TSX/SCSS/CSS straight into your project using local imports.
Who it's for: developers working in React + TypeScript + Sass projects who want accessible components and a token-driven theming system without taking on a new runtime dependency.
Plugins in this marketplace
| Plugin | Version | What it ships |
|---|
acss-kit | 1.0.0 | Accessible React components, static HTML snippets, OKLCH CSS themes, and Tailwind-style utility classes for fpkit/acss projects. All /utility-* commands are now part of this plugin (replaces acss-utilities). WCAG 2.2 AA validation built-in. See docs/migration-v1.md if upgrading from v0.x with acss-utilities installed. |
acss-utilities | 1.0.0 | Deprecated. All utility-class commands have moved to acss-kit v1.0.0. Existing installs continue to work; no new features will be added. Uninstall and update acss-kit — see migration-v1.md. |
style-agent | 0.2.0 | Framework-agnostic CSS authoring skills. /css-to-class extracts utility-class lists into a single named class; /inline-style-to-class converts inline styles or JSX style objects into a named class appended to the project stylesheet. Works with plain CSS, SCSS, Tailwind, or any utility-first workflow. |
The three plugins are decoupled — install any combination independently.
Why agent-driven instead of an npm package?
Most UI component libraries ship as npm packages. That model works, but it comes with trade-offs that compound over time:
- Install weight — every team member and CI runner downloads the package, its transitive dependencies, and the bundler overhead needed to tree-shake it.
- Update risk — a semver-minor bump in an upstream component library can silently change behavior, break accessibility patterns, or introduce API incompatibilities that take hours to track down.
- Ownership ceiling — once you depend on an npm package you can only customize what the package author exposed as props. Deeper changes mean forking, which puts you on the hook for rebasing security fixes forever.
- Lock-in — pinning to a specific version to stay stable means you miss bug fixes; upgrading means re-testing every consumer.
This project explores a different trade-off: components and themes live in your project as plain TSX/SCSS files generated by an agent, not as imported library code. The agent carries the reference docs, the accessibility patterns, and the OKLCH palette logic as skills. When you need a component, the agent reads the canonical spec and writes the file directly into your source tree.
The benefits of this approach:
| Concern | npm package | Agent-driven |
|---|
| Install time | Grows with each dependency | Zero — no package to install |
| Customization | Limited to exposed API surface | Full source ownership — edit anything |
| Update breakage | A bump anywhere in the tree can break you | You control when and what changes |
| Bundle size | Requires tree-shaking, side-effect auditing | Only the components you actually use exist |
| Accessibility drift | Depends on upstream diligence | Each component is generated from a versioned, auditable spec |
| Onboarding | Requires understanding the library's API | The agent explains and generates — ask in plain English |
The catch: this is still an evolving idea. The agent-as-package model raises real questions around reproducibility, diff-ability of generated output, and how to roll a fix across many projects at once. We're working through those — which is why the experimental warning is at the top.
Quickstart
Inside any Claude Code session running in your React + TS project — register the marketplace once, then install whichever plugin(s) you need:
