# system24 ships ten whole theme files, and the link install takes your variables away

> refact0r/system24 is a CSS theme for Discord clients, built on top of a separate repository that holds the core styles. The theme itself is easy to install; the friction is in what the two install paths let you change afterwards, in the two tracked copies of every edit, and in a package manifest that names something else entirely.

**refact0r/system24** — a tui-style discord theme

- Repository: https://github.com/refact0r/system24
- Stars: 2,412 · Forks: 169
- Language: CSS
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/refact0r-system24

## The link install works but quietly removes the variables you would edit

Two install paths exist and they are not equivalent in what they let you do afterwards. The file path is three steps: open `system24.theme.css` in the repository's theme directory, take the download button at the top right of that page, and drag the file into the theme folder that the client's theme settings can open for you. The optional third step is to open the file and edit the CSS variables within. The variable block is right there in the file you just dropped in, so a color change is a local edit that no other tool has to know about.

The link path replaces the download with a URL added to the theme import links:

```
https://refact0r.github.io/system24/build/system24.css
```

That URL points at the build directory rather than the theme directory, and it brings the same CSS with no variables block to edit. The README resolves the gap in one sentence: you will need to copy the theme variables to your QuickCSS in order to customize the theme. So the two paths deliver identical pixels and different editability, and the reader who starts with the link has to discover the copy step before they can change anything. The QuickCSS destination also means the customization lives in the client rather than in the theme file, so it survives a theme update differently than an edit to the downloaded file would, and a reader who mixes the two routes ends up with variables in one place and overridden styles in the other.

## Every change has to be written twice, once in src and once in build

The repository tracks two copies of the stylesheet. A dev script watches the `.css` files under `/src` and combines them into a build file under `/build`, and both locations are committed to git. The contributing section states the consequence directly: any changes you contribute should exist in both places.

That is a real maintenance hazard rather than a formality. A pull request that edits `src` and regenerates nothing produces a reviewable diff that does not match what users download, and a pull request that edits only `build` gets overwritten by the next build. The dev script exists to prevent the second case, but the first still depends on the contributor remembering to run it. The project also asks contributors to consider which theme they actually want to work on before opening a pull request, which suggests the same class of confusion is expected often enough to be worth a warning.

The practical habit this forces is simple: run the build, stage both trees, and check that the diff contains the same lines twice. Nothing in the tooling enforces it.

## Local development needs a .env file with an absolute Windows path

Running the theme locally takes four steps: clone the repository, run `npm i`, create a `.env` file in the project root holding the paths of any local theme files you want updated as a comma separated list, then run `npm run dev`. The example given is a Windows path into the client's own themes directory:

```
DEV_OUTPUT_PATH=C:\Users\USERNAME\AppData\Roaming\Vencord\themes\system24-dev.theme.css
```

Two details are worth reading closely. The output goes into an installed client's themes folder rather than into the repository, so the loop depends on a real Vencord profile existing on the machine, and the `.env` entry has no default. On a machine with no such profile the build script has nowhere to write, and nothing in the instructions says what happens then. The comma separated list implies more than one destination is allowed, so a contributor can fan one build out to several clients at once, which is where the naming gets ambiguous: nothing in the variable name says which client a given path targets.

After the watcher starts, editing any file under `/src` or the main theme file updates every path listed in the `.env` and the build file in `/build`, and the contributor opens a pull request with the result. The `dotenv` dependency exists to read that file and `chokidar` is what watches `/src` for the changes that trigger a rebuild.

## package.json calls the package systemtheme and ships four scripts, two of them undocumented

The manifest disagrees with the repository on the first line that matters. The directory is `system24`, the theme file is `system24.theme.css`, and the package name field reads `systemtheme`, at version 2.1.0. The repository has no GitHub releases, so that version string is the only place a number for the theme is written down, and the last push to `main` is dated 2026-09-16.

Four scripts are defined:

```
"build": "node scripts/build.js",
"dev": "node scripts/dev.js",
"serve": "node scripts/serve.js",
"screenshot": "node scripts/screenshot-flavors.js"
```

The contributing instructions only ever call `npm run dev`. `build`, `serve` and `screenshot` appear nowhere in the guide, so a contributor who edits `src` without running the build first is working from a workflow the manifest does not explain. The screenshot script name also tells you what the `assets/flavors` images are: generated, not hand-made, one per flavor.

There are two dev dependencies and no dependencies at all, which is why a CSS project needs `npm i` before it can do anything. There is also no test script of any kind, while a `benchmark/` directory is tracked at the top level. Nothing in the manifest points at it.

## Each flavor is a complete theme file rather than a set of overrides

Flavors are described as preset customizations, and the install section explains how to use one: follow the same steps but download the flavor theme file of your choice instead of `system24.theme.css`, clicking a flavor name in the table to open its file and a preview image to see it at full size. Each flavor is a standalone file under the flavors directory, named `system24-<flavor>.theme.css`, and each is paired with a full size screenshot stored under `assets/flavors`.

There are ten of them: light, auto, catppuccin mocha, catppuccin macchiato, everforest, rose pine, rose pine moon, tokyo night, nord and vencord. Nine are palette or scheme names borrowed from other projects, and the tenth, vencord, is named after the client rather than a color scheme, which suggests it adjusts the theme for that client's own interface rather than restyling the palette. The auto entry is named for a behavior rather than a scheme, following the system theme, and is the only one of the ten carrying a parenthetical note.

Because each flavor is a whole file, the choice is exclusive. You install `system24-light.theme.css` or you install `system24.theme.css` and edit it, and the README does not describe a way to layer one on top of the other or to start from a flavor and then override single variables. The two edit routes also do not combine cleanly: the flavor path has no documented variable block, and the link path has none either, so a customized flavor means editing whichever file you downloaded.

## One flavor carries a behavior note and the rest carry only a name

Nine entries in the flavor table are a link and a picture. One, auto, adds a parenthetical note reading follows system theme. That single annotation is the only behavioral description anywhere in the table, and it is the one entry where what the file does at runtime differs from what its name suggests: an automatic variant has to react to the client setting, while a static palette does not.

The consequence for anyone choosing a flavor is that nine of the options are named but not characterized. Everforest, rose pine, tokyo night and nord are recognizable to people who use those palettes elsewhere, but nothing in the repository says how faithfully they are reproduced, whether the accent colors were adjusted for readability on a chat background, or whether any of them was checked for contrast against the client's own text colors. The preview images are the only evidence offered, and they are static renders.

The table layout also shows the gap: the final row carries the vencord entry and two empty cells at 33 percent width each, so the grid is sized for twelve flavors and holds ten. Adding one means editing the HTML rather than dropping a file into the directory.

## The core styles are a second repository and the root has four instruction files

The theme depends on another project for its core styles, midnight, maintained under the same account. That split is stated in the contributing section with an unusual warning attached: if you are looking to contribute, please consider which theme you actually want to work on, and feel free to open an issue and ask if you are unsure. In other words, the maintainer expects people to arrive intending to edit the core layer and end up here instead, which is what happens when the visible theme is a thin file over someone else's base. The design credit points the same way, naming a Spicetify text theme as the primary inspiration.

The root reflects that arrangement. Alongside `README.md` there are `CONTRIBUTING.md`, `AGENTS.md`, `CLAUDE.md` and a `.codex/` directory, so the same contribution guidance is addressed to humans in two places and to coding agents in two more, while the styles themselves live across two repositories. A `docs/` directory and a `benchmark/` directory are tracked as well, and neither is referenced from the README. Support goes through a Discord server invite for help, feedback and notification of upcoming changes, which is the only channel the project names.

For a reader deciding whether to adopt the theme, the practical question is what happens when the base repository changes. The core styles are versioned somewhere else, the theme above them is versioned here at 2.1.0, and nothing in the manifest pins a version of the base.

## Conclusion

Pick system24 if you want a terminal-look theme on Vencord, BetterDiscord or anything else that reads a theme file, and if you are willing to treat CSS variables as the customization surface. Check three things first. If you want to tweak colors later, install the file rather than the link, because the link path leaves your variables behind unless you paste them into QuickCSS yourself. If you plan to send a pull request, remember that changes have to land in both `src` and `build`. And if you are evaluating the repository rather than the theme, notice that the core styles live in a second repository, so the theme you are reading is only the layer above them.

## FAQ

### How do I install the system24 Discord theme?

Download `system24.theme.css` and drag it into the theme folder that the client's theme settings can open, or add `https://refact0r.github.io/system24/build/system24.css` to your theme import links. Vencord, BetterDiscord and any client that supports theme files are named.

### Can I edit the system24 colors after installing it by link?

Only by copying the theme variables to your QuickCSS. The README states you will need to copy the theme variables to your quickcss in order to customize the theme when the theme is installed through a link.

### What flavors does system24 ship?

Ten: light, auto, catppuccin mocha, catppuccin macchiato, everforest, rose pine, rose pine moon, tokyo night, nord and vencord. Each is a separate `system24-<flavor>.theme.css` file installed in place of the base theme file.

### What has to be edited in a system24 pull request?

Both trees. The dev script combines the `.css` files under `/src` into a build file under `/build`, and both are tracked in git, so contributed changes have to exist in both places.

### Where do the core styles of the system24 theme come from?

From a separate repository, midnight, under the same account. The README states the theme depends on it for its core styles and asks contributors to consider which theme they actually want to work on.

## Sources

- [Issues](https://github.com/refact0r/system24/issues)
- [License: MIT](https://github.com/refact0r/system24/blob/main/LICENSE)
- [README](https://github.com/refact0r/system24/blob/main/README.md)
- [refact0r/system24 on GitHub](https://github.com/refact0r/system24)

---

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