slackthemes is a Middleman site where Slack themes are shared as YAML entries

A catalogue site, not a theme package

The project describes itself in one line as a platform for browsing and sharing themes for Slack, and the README adds a disclaimer that it is not affiliated with Slack in any way or form, while still calling it a great tool worth using.

That disclaimer is not incidental. A Slack theme is not a plugin with an API, and the project does not pretend otherwise. What is here is a website that lists themes and lets people find them, plus the machinery to submit new ones. The homepage is slackthemes.net, and the repository is the source for that site rather than a library you would add to a project.

The repository layout confirms it. The tree holds a `Gemfile` and a `Gemfile.lock`, a `config.rb` which is where a Middleman site keeps its configuration, a `data/` directory, a `lib/` directory for Ruby helpers and a `source/` directory that is the site content, plus a `.github/` directory with a build workflow. The primary language is recorded as HTML, which is a fair description of what a static site generator produces.

There is a build badge wired to a GitHub Actions workflow called `build.yml`, so the site is compiled on the repository's own infrastructure rather than by hand.

One fact to settle early is the licence. The repository carries a `LICENSE` file in the tree, but no recognised licence identifier is attached to it, so a theme you find through the site comes without clear reuse terms, and the site itself is in the same position. Anyone planning to publish a theme, or to reuse one listed there, needs to work that out from the file itself.

Middleman generates a static site from a YAML catalogue

The build tool is Middleman, and the README's core contribution steps name it directly. The workflow for a core change is short.

2. Install dependencies using `bundle install`

4. Build the project using `bundle exec middleman build`

That second command compiles the site into a `./build` directory, and the README points out that you can run a local web server to test the project, with the instruction to use the `./build` folder as your DocumentRoot. That is the standard Middleman output convention, and it tells you the deployment model: the result is static files that any web server can serve.

The content model is equally simple. Middleman keeps data in a `data/` directory and exposes it to templates, and this project uses exactly one file for its catalogue.

1. Fork this project.
2. Add your theme to the `data/themes.yml` file.
3. Create a pull request.

So a theme is a record in a YAML file. The site templates read that file and render the entries, which means adding a theme does not touch a template, a stylesheet or a build script. It also means the catalogue is versioned with the code, and every change to the list is visible as a diff in a pull request.

That model has an obvious upside and an obvious limit. The upside is reviewability, since a pull request shows exactly what was added to the list. The limit is that the list is edited by hand, so a submission can be wrong, incomplete, or inconsistent with the fields the templates expect, and nothing in the documented workflow checks that beyond a human reading the diff.

Sharing a theme is a pull request, not an upload form

The contribution path for themes is the second half of the README's instructions, and it deserves to be read as a design decision rather than a formality.

A theme author forks the repository, adds an entry to `data/themes.yml`, and opens a pull request. There is no account, no submission form, and no backend service in the tree. The site's directory listing is the catalogue.

The practical consequence is that publishing a theme requires Git familiarity and a review cycle. For a community catalogue that keeps a human in the loop, that is a reasonable trade. For someone who wants to share a theme quickly without touching Git, it is a barrier, and the README offers no alternative path.

The core contribution path is documented separately, and it is aimed at people who want to change the site itself rather than its content. Those steps are: install dependencies with `bundle install`, make changes, build the project, and run a local web server with the `./build` folder as the DocumentRoot before opening a pull request. The order matters, because building before serving is what makes the local check meaningful.

The two paths in the README are the whole governance model of the project. Content goes through data, code goes through a build, and both end in a pull request. The repository also has a `lib/` directory, which in a Middleman project is where helper Ruby code and custom generators live, so the ability to extend the site beyond the default templates is there even though the README does not describe it.

A stale push and no releases say more than the badge does

The maintenance picture is thin, and the honest reading is worth stating.

The repository is not archived. The last push was on 2026-05-16, and there are no GitHub releases at all, so there is no version history to consult and no changelog to diff. The build badge in the README reflects whether the workflow passed on the default branch, which tells you the site still compiles and nothing more.

For a project whose value is its catalogue, that gap has a specific shape. The themes listed on the site reflect the state of `data/themes.yml` at the last push. A theme that a vendor has since dropped, or a Slack client version that has changed how themes are applied, will still be listed, because nothing in the documented workflow flags an entry as stale. The README does not describe a way for a listed theme to be marked as unmaintained, and it does not explain who reviews entries for currency.

The offsetting point is that the project is a static site with a build step and no runtime dependency to patch. A fork can be built and deployed as it stands, and the Ruby dependencies are pinned in `Gemfile.lock`, so a rebuild is reproducible. There is also no database to migrate, no user data to protect and no service to keep running, which is a genuinely different maintenance profile from an application.

The `LICENSE` file in the tree, with no recognised licence identifier attached to the project, is the other open question. Combined with a last push in May 2026, a deployment decision should be based on the code as it stands rather than on any expectation of ongoing review.

What this is not

It is easy to mistake this project for something with more capability than it has, so the boundaries are worth listing.

It is not a theme packager. There is no documented tool that takes a theme and produces an installable artifact, and the contribution flow ends at an entry in a YAML file, so whatever the site presents is what a browser displays.

It is not a client. There is no application code that applies a theme to Slack, and nothing in the tree touches the Slack desktop client or the browser client. A theme is content, and the site is a way to find content.

It is not an affiliation with Slack, which the README states twice over. The project is a third-party catalogue built on someone else's product, and the trademarks and product decisions belong to their owners.

For a reader who wants a working theme, the practical path is to find an entry on the site and follow whatever the entry itself describes. For someone who wants to contribute, the path is a fork, an edit to `data/themes.yml`, and a pull request, with a local build to check the result. The alternative worth naming is keeping your own list of themes, since the value of the site is the shared catalogue, and a personal list needs none of this infrastructure.

Editorial conclusion

slackthemes fits someone who wants to collect and share Slack client themes, or a maintainer who likes the model where a catalogue is a versioned data file and the site is generated from it. Skip it if you expected a theme packager, an installer or a desktop client, since the repository ships a website and its build, and skip it if you need a project with a documented licence, because this one has no recognisable licence file. Verify first that the theme format you want to publish matches the existing entries in data/themes.yml, and that the site builds on your machine with bundle exec middleman build before you open a pull request.

Frequently asked questions

Official sources

1. Issues
2. paracycle/slackthemes on GitHub
3. Project website
4. README