# Primer CSS: GitHub's design system as a Sass package, now in KTLO mode

> Primer CSS ships GitHub's utility and component styles as an npm package of SCSS partials. The README states the project is in KTLO mode, which changes who should reach for it and who should use primer/react instead.

**primer/css** — Primer is GitHub's design system. This is the CSS implementation

- Repository: https://github.com/primer/css
- Website: https://primer.style/css
- Stars: 13,023 · Forks: 1,286
- Language: SCSS
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/primer-css

## What Primer CSS actually is, and the KTLO notice at the top of the README

Primer is GitHub's design system, and this repository is its CSS implementation, written in SCSS. The package published to npm is @primer/css, and the README describes it in one line: the CSS implementation of GitHub's Primer Design System. That framing matters, because it tells you this is one layer of a larger system rather than a standalone framework with opinions about markup and behavior.

The most important sentence in the README is a warning block: the project is in KTLO mode, which stands for keep the lights on. The README's own guidance is to use existing utility classes from this project where needed, and to reach for primer/react or, if necessary, primer/view_components when you want more complete patterns that include styling and markup. That is an unusually direct statement from a design system about where new work should go. If you are choosing a styling foundation today, the README is telling you that the component-level thinking lives elsewhere, and this package is the utility layer that other things build on.

The repository is not archived, and the last push was on 2026-09-21. Recent releases include v22.3.0 on 2026-06-17, v22.2.1 on 2026-06-12 and v22.2.0 on 2026-05-18. The package.json in the repository lists version 22.3.1. So there is still release activity, but the KTLO framing sets expectations: this is maintenance of a stable surface, not a project racing to add new patterns.

## How the Sass modules are split: core, product and marketing

The mechanism is straightforward Sass. The published package contains SCSS source, and the README shows the top-level import as index.scss. It also shows that you can import individual Primer modules directly from the package: core, product and marketing each expose their own index.scss.

That three-way split is the architecture worth understanding. Core is the shared base. Product and marketing are separate groupings, which suggests GitHub itself uses different styling needs for application surfaces versus promotional pages. If you import the top-level index, you are pulling in the union of those modules. If you import only what you need, your compiled CSS is smaller and your upgrade surface is narrower.

The package.json declares sass: index.scss and style: dist/primer.css, so tooling that understands the sass field can resolve the source entry point, while a plain CSS consumer can point at the built file. The build scripts in package.json are named build:css, dist and dist:watch, with dist:watch running chokidar over src/**/*.scss and re-running script/dist.js. That is the data flow on the maintainer side: SCSS in src, compiled output in dist. On your side, the flow is your Sass compiler reading from node_modules.

One practical consequence of shipping source rather than only compiled CSS: your build can theme and extend, but it also inherits the cost of compiling the partials. The README does not document a prebuilt CDN URL, so treat dist/primer.css as something you serve from your own build rather than a hosted asset.

## Installing @primer/css and compiling your first stylesheet

The README gives the install command directly. Node 16 or newer is required according to the engines field in package.json.

```bash
npm install --save @primer/css
```

After that, the README says to add your project's node_modules directory to your Sass include paths (also called load paths), then import the package. The exact import line from the README is a bare package path, which is why the load path matters:

```scss
@import "@primer/css/index.scss";
```

If you would rather pull in only part of the system, the README shows importing modules individually:

```scss
@import "@primer/css/core/index.scss";
@import "@primer/css/product/index.scss";
@import "@primer/css/marketing/index.scss";
```

What you should see after compiling is a stylesheet containing Primer's utility classes, which you then apply as class names in your markup. The README does not walk through a rendered example page, so the first real use is: compile the import, inspect the output CSS for the utility class names, and apply them in a template. The documentation site at primer.style/css is where the README points for getting started, components, theme and principles; the README itself stays short and defers to that site.

## Where Primer CSS is the wrong tool

The clearest failure mode is expecting components. The README's warning says to use primer/react or primer/view_components for complete patterns that include styling and markup. Primer CSS gives you the styling half. If your team wants a dropdown, a dialog or a form control that arrives wired up, this package does not provide the wiring, and adopting it means writing your own markup and behavior against the class names.

A second constraint is the Sass dependency. The source files are SCSS, and the README's usage instructions assume a Sass pipeline with configured include paths. If your build has moved to plain CSS, or to a toolchain that does not resolve Sass load paths from node_modules, the documented import will not work as written. The package does declare a style field pointing at dist/primer.css, but the README does not document that path as the recommended entry point, so you would be relying on package metadata rather than documented usage.

A third issue is scope. Because the top-level index pulls in core, product and marketing together, a small project that imports index.scss gets CSS for surfaces it may never render. The README offers per-module imports as the alternative, but it does not quantify the difference, and it does not document a way to tree-shake individual utilities. If bundle size is your primary constraint, this is a package you configure carefully rather than drop in.

## Primer CSS versus primer/react: same system, different layer

The real alternative is not another CSS framework. It is primer/react, which the README names directly in its warning. The difference in approach is where the abstraction sits. Primer CSS is a Sass package: you import partials, compile them, and apply class names in whatever markup you already have. primer/react is a component library: the styling and the markup arrive together as React components, and you compose them rather than writing class names by hand.

That distinction drives the decision. If your application is server-rendered templates, Rails views or plain HTML with a Sass pipeline, primer/react is not an option, and Primer CSS is the layer that fits. If your application is React and you want GitHub's patterns rather than GitHub's primitives, the README's own recommendation points away from this package. There is also primer/view_components, which the README lists as the fallback for complete patterns outside React.

The trade-off is control versus assembly. With Primer CSS you decide the markup, which means you can match an existing DOM structure and adopt the design system incrementally. With the component layers you get consistency faster but inherit their rendering decisions. Neither is better in the abstract; the README simply states which one GitHub wants new work to use.

## Maintenance, upgrades and the MIT licence

Upgrade cost is shaped by the module split. If you import only core, an upgrade that touches product or marketing does not reach you. If you import index.scss, every release is potentially your concern. The repository uses changesets for release management, visible in the .changeset directory and the release script that runs changeset publish, and it keeps a CHANGELOG.md. There is also a deprecations.js file at the top level, which suggests deprecated classes are tracked in code rather than only in prose, though the README does not explain how that file is consumed by consumers of the package.

The KTLO notice is the main maintenance signal. It is not the same as abandonment: the last push was on 2026-09-21 and releases shipped in mid-2026. But the README's instruction to use existing utility classes where needed, and to go elsewhere for complete patterns, tells you the direction of new development. Budget for the possibility that a pattern you want will never be added here.

The licence is MIT, stated in the README and in package.json, with copyright to GitHub. MIT is permissive and places few obligations on how you redistribute the compiled CSS. This is a description of the licence identifier, not legal advice; if your organisation has specific compliance requirements around attribution or bundled assets, have someone qualified review the LICENSE file at the repository root.

## Conclusion

Adopt Primer CSS if you already build with Sass and want Primer's utility classes without pulling in a React component layer; the README explicitly directs anyone who needs complete styled patterns to primer/react or primer/view_components, so treat this package as a styling layer, not a full UI kit. Verify two things before committing: that your Sass build can resolve the @primer/css load path, and that the modules you import (core, product, marketing) match the surfaces you actually ship, because importing index.scss pulls in all of them. The README's KTLO notice means you should expect maintenance of what exists rather than new patterns, and plan accordingly.

## FAQ

### Is Primer CSS still maintained?

The repository is not archived and the last push was on 2026-09-21, with releases in mid-2026. However, the README carries a warning that the project is in KTLO mode and directs new work toward primer/react or primer/view_components.

### How do I install Primer CSS?

The README gives the command npm install --save @primer/css, which requires Node 16 or newer according to package.json. You then add node_modules to your Sass include paths and import the package.

### Does Primer CSS include components with markup?

No. The README states that for more complete patterns that include styling and markup you should use primer/react or, if necessary, primer/view_components.

### What licence does Primer CSS use?

The README and package.json both state the MIT licence, with copyright to GitHub.

## Sources

- [License: MIT](https://github.com/primer/css/blob/main/LICENSE)
- [primer/css on GitHub](https://github.com/primer/css)
- [Project website](https://primer.style/css)
- [README](https://github.com/primer/css/blob/main/README.md)
- [Releases](https://github.com/primer/css/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/primer-css