ray.so: Raycast's open source snippet, prompt and theme browser
Create code snippets, browse AI prompts, create extension icons and more.
At a glance
- What is it?
- Raycast publishes ray.so as a Next.js app with seven tool pages. The interesting part is not the design work, it is that the data files are the contribution surface.
- Who is it for?
- ray.so is best understood as a publishing surface with a web front end rather than as an application you would fork to build on. The seven tools share one rendering stack, and the content that makes them useful lives in plain TypeScript data files that anyone can edit through a pull request.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 27 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Seven tools on one Next.js app
The repository is the source for ray.so, a collection of small tools built by Raycast, and the README enumerates all seven. Code Images turns a snippet into a shareable image. Icon Maker produces icons for Raycast extensions. Prompt Explorer, Preset Explorer, Quicklink Explorer, Snippet Explorer and Theme Explorer are five browsers over content that already exists inside Raycast, each with an import path back into the app.
The split matters. Three of them generate something new from what you paste in, and four are catalogues over Raycast's own library. If you came looking for a code snippet renderer, that is one page. If you came looking for the source of the prompt library, that is a different page and a different set of files.
The dependency list in `package.json` explains the shared implementation. `html-to-image` and `sharp` cover the code image rendering path, `highlight.js` does syntax colouring, `jszip` handles the theme export format, `@vercel/og` generates social images, and `@raycast/icons` supplies the icon set. `@astral-sh/ruff-wasm-web` is the unusual one: Python linting compiled to WebAssembly, running in the browser rather than on a server, which tells you the lint step for Python snippets happens client side.
Running it locally with npm install and npm run dev
The setup section is three lines long and assumes you already know Next.js, which the README says outright:
npm install
npm run devThe scripts in `package.json` show what else exists. `next dev` for development, `next build` and `next start` for a production build, `eslint .` for linting, and `tsc --noEmit` for a type check under the name `type-check`. There is one script that has nothing to do with the framework: `update-models` runs `node scripts/update-ai-models.mjs`, which is how the AI model list behind the prompt tools is refreshed.
Two version constraints are worth noticing before you start. `engines.node` is pinned to `^22`, so Node 20 will not do. And the manifest is marked `private` with version `0.1.0`, which tells you this package is not published to a registry and is not intended to be consumed as a dependency. You run it from a clone.
The repository also wires up linting and formatting on commit through husky, configured through `.lintstagedrc.js`, `.prettierrc.json`, `.stylelintrc` and a separate `eslint.config.mjs`. If you open a pull request, expect those to run against your change.
The data files are the contribution surface
This is the part that makes the repository approachable. For prompts, presets, quicklinks and snippets, the README's instructions are to open one of four named TypeScript files, add your data to the right category, include all fields, keep entries unique within their category, add your name and an optional website to the `author` field, then open a pull request.
The four files are named in the README as `prompts.ts`, `presets.ts`, `snippets.ts` and `quicklinks.ts`, each living under its own route directory. Because they are typed and linted, a malformed entry is a build failure rather than a runtime surprise, which is a better contributor experience than editing raw JSON would give you.
The uniqueness requirement within a category is the one rule that surprises people. Adding a prompt that already exists is rejected even if your version is worded differently, so search the file before writing.
Themes work differently because the JSON does not originate in this repository. The flow the README describes is: open Theme Studio inside Raycast, right click your theme, choose Copy as JSON, create a folder under `themes/` named after your Raycast username, create a file named after the theme, and paste the JSON in. So a theme contribution is a transcription step from a desktop app into a folder named for you.
Why new code themes are steered away from a pull request
The README carves out an exception with a note that anyone contributing graphics will read twice. If you want to add a new code theme, it recommends forking the project and running your own version rather than contributing upstream. Certain partner themes may be considered, but the route is to open an issue or email the address in the README first.
That asymmetry is worth understanding rather than resenting. The other five data types are additions to an open library where Raycast gains entries. A code theme is a visual design that would ship under Raycast's name on a page Raycast controls, which is a different kind of decision with a different review burden.
The practical upshot for a contributor is that the cheapest path to a custom code theme is a fork. You get the whole app, the theme JSON is yours to edit, and you can run it locally with the two commands above. If you think a theme is good enough to belong upstream, the README asks for a conversation before you write the code, which is the correct sequence.
The last push to the repository was on 2026-09-15, and the repository publishes no GitHub releases, so the deployed site at ray.so is the only place to see current content.
What a contributor gets and what Raycast keeps
The contribution policy is stated in one sentence: contributions are welcome primarily in the form of new presets, prompts, snippets, themes, and bug fixes. The list is the policy. Presets, prompts, quicklinks and snippets are all handled through the data-file route, and themes have their own multi-step procedure.
Nothing in the README describes a general feature contribution, a new tool page, or a change to the rendering pipeline. That is not a gap so much as a boundary. This is a site with seven defined pages, not a plugin platform, and adding a page means owning a route, a navigation entry and whatever data model it needs.
The MIT licence in the repository root is the permissive end of the scale, so forking to run your own version costs nothing legally. `package.json` also records an npm homepage pointing at the repository README and a bugs URL, which is the conventional way to file the issues the README keeps asking for.
If you are evaluating this as a base for something else, the honest read is that the valuable parts are the rendering approach for code images and the export plumbing for themes, both of which live in `components/` and `utils/`. The content libraries are the project's actual product, and they are worth contributing to rather than extracting.
Editorial conclusion
ray.so is best understood as a publishing surface with a web front end rather than as an application you would fork to build on. The seven tools share one rendering stack, and the content that makes them useful lives in plain TypeScript data files that anyone can edit through a pull request. The one part the README asks you not to touch casually is new code themes, which it steers toward forking or a prior conversation with the team. Clone it, run `npm install` and `npm run dev`, add your entry to the relevant data file, and read the contribution notes before you pick a category.
Frequently asked questions
What tools does ray.so actually provide?
Seven pages: Code Images for turning code into an image, Icon Maker for Raycast extension icons, and five browsers over Raycast's own library, namely Prompt Explorer, Preset Explorer, Quicklink Explorer, Snippet Explorer and Theme Explorer. Three generate something from what you paste in, and four are catalogues with an import path back into Raycast.
How do I run ray.so locally to contribute a prompt or a snippet?
Clone the repository, run `npm install`, then `npm run dev`. Node 22 is required because the package manifest pins engines to `^22`. Prompts, presets, quicklinks and snippets are added by editing the relevant data file under its route directory, so no component work is involved.
Can I add my own code theme to ray.so through a pull request?
Not directly. The README recommends forking the project and running your own version for a new code theme. Certain partner themes may be considered, but the route is to open an issue or contact the team before writing the code, because a code theme ships under Raycast's name on a page it controls.
Why does the package manifest mark ray.so as private?
Because it is not published to any registry and is not meant to be consumed as a dependency. The manifest is marked `private` at version `0.1.0`, with the npm homepage pointing back at the repository README. You run ray.so from a clone, which is why the setup instructions are install and dev rather than install and import.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/raycast-ray-so)