Raycast extensions: a store, a policy, and a repository that is mostly other people's code

The repository is the store, not a framework

Raycast lets you control your tools with a few keystrokes, and this repository contains all extensions that are available in the Raycast Store. It also includes documentation and examples of how to extend Raycast using React.

That sentence is the whole scope. The product is a keyboard launcher; the repository is the catalogue of things other people built for it; and the extension model is React components that call a Raycast API.

The practical consequence is that there is nothing here to install. You do not add this repository as a dependency, and there is no runtime component to it. A developer reads it the way you read a pattern library.

And the split is visible in the root listing: `extensions/` for the extensions themselves, `docs/` for documentation, `examples/` for examples, and two directories whose purpose is inferred from their names, `migrations/` and `templates/`.

That is a repository shaped like a marketplace, which is also why the README spends most of its words on policy.

Three documents to read before you submit anything

The Getting Started section points at developers.raycast.com for the API and at the Raycast Store for discovering and installing extensions. Then it says to be sure to read and follow the Community guidelines, the Extension guidelines and the Acceptable Use Policy when submitting your extension and interacting with other folks in this repository.

Three documents, named separately, with links to the manual for the first two and to raycast.com for the policy. That is an unusual amount of ceremony for an open source repository, and it is the clearest signal about what this project is: a moderated catalogue rather than a free-for-all collection of scripts.

For someone writing their first extension it means the review criteria are published, which is better than discovering them through a rejected pull request.

For someone reading the repository it means the code you are copying was written under rules you should read, particularly around what an extension is allowed to do on a user's machine.

Feedback goes through issue templates, and API questions are welcome there

The Feedback section is unusually specific about where things belong.

It asks you to use GitHub issues for everything API related: bugs, improvement suggestions, developer experience, docs. The issues link goes to a chooser rather than a blank form, and the README adds that a few templates, linked to developers.raycast.com/examples, should help you get started.

The framing is also direct about why: Raycast wouldn't be where it is without the feedback from our community, so they would be happy to hear what you think of the API and the developer experience and how they can improve.

So there are two feedback channels with different purposes. Issues are for the API and the developer experience, and the Slack community is for everything else: sharing your extension, debugging nasty bugs, or getting to know like-minded folks.

That split is worth respecting if you are filing an issue about the platform rather than about one extension's code.

templates/ and examples/ are where you start, and they are different things

There are two directories that both look like starting points and are not the same.

`templates/` at the repository root is the scaffolding. When you add an extension, you are adding code to this repository, so a template is the shape that new extension is expected to take, and its presence at the root next to `extensions/` rather than inside `examples/` is the tell.

`examples/` is for learning. It contains `api-examples/`, and four extensions: `doppler-share-secrets`, `hacker-news`, `spotify-controls` and `todo-list/`.

Between the templates and those four examples, you have both a skeleton and working extensions to compare against.

migrations/ is how a catalogue handles an API that moves

A repository holding many extensions has a problem a single package does not: when the Raycast API changes, every extension that used the old shape has to change with it.

The `migrations/` directory at the root is the answer to that. Its name suggests that is where such API changes are handled.

This is also the reason to read the repository's history before copying an extension. An example that looks dated may be exactly what the API required at the time it was written.

The `scripts/` directory at the root is the other half of the same concern: automation for a repository with many similar entries, whether that is validating manifests, running checks across every extension, or generating something from a shared source.

No releases, and a repository that changes daily rather than by version

The repository has no GitHub releases, and the last push to main was on 2026-11-02.

That is the right shape for this project. There is nothing here to version, because an extension is installed from the Raycast Store by name, and a change to an extension reaches users when the store updates it, not when a tag is cut here.

So the commit history is the changelog. If you are tracking whether an extension has been fixed, the answer is in its commits rather than in a release note.

The other root files are the usual governance set: CONTRIBUTING.md, SECURITY.md, LICENSE, and a `.nvmrc` pinning the Node version used to develop in the repository.

Editorial conclusion

raycast/extensions suits someone who wants to see how a working Raycast extension is structured, either as a starting point or as a reference before submitting their own. It does not suit you as a library to depend on, since it is a catalogue of applications rather than a package, and it does not suit you if you want to publish without reading the guidelines, because the README explicitly requires following the community, extension and acceptable use policy documents. Verify three things before you contribute: which of the three guideline documents applies to what you are doing, since the README names them separately, whether your extension needs a migration entry, given the migrations directory at the root, and which template you start from, since templates/ sits beside the extensions and the examples.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository