A Raycast extension doesn't have one name. It has a name field and a title field at the extension level, a name and title for every command inside it, and an optional subtitle on top of that — each one governed by a slightly different rule, and each one worth getting right before you submit rather than after a review comment sends you back to fix it. Here's what Raycast's own developer documentation actually says about each of them.
Two identifiers, one extension
The extension's manifest documentation describes the name field as “a unique name for the extension. This is used in the Store link to your extension, so keep it short and URL compatible.” The title field is described separately: “the title of the extension that is shown to the user in the Store as well as the preferences.” One is a technical identifier, functionally similar to a GitHub repo slug or an npm package name. The other is what a person actually reads. Treating them as the same decision is how extensions end up with an awkward Store URL, a confusing display title, or both.
Titles follow Raycast's own style rules
Raycast's guide to preparing an extension for the Store sets specific style conventions for both extension and command titles. Capitalization follows the Apple Style Guide, which allows lower case for names and trademarks that are canonically written that way — their own examples are iOS, macOS, and npm. Extension titles should make it easy to understand what the extension does at a glance, favor nouns over verbs, and avoid generic naming when the extension only offers a small number of commands. Command titles typically follow a “<verb> <noun>” structure or stand alone as a noun, skip articles, and go beyond just naming the service they connect to.
Subtitles add context. They don't repeat the title.
The same guide is direct about subtitles: “Use subtitles to add context to your command. Usually, it's an app or service name that you integrate with,” and a subtitle should never function as a command description. If a subtitle would almost duplicate the command title, Raycast's own advice is to leave it out entirely. Their documentation illustrates this with a Xcode-integration command titled “Search Recent Projects,” where the subtitle supplies real context rather than restating what the title already says. A command whose title already states its function plainly rarely needs a subtitle attached to it at all.
Command names map to real source files
The command-level name field isn't purely cosmetic either. The manifest documentation states that a command's name is “a unique id for the command. The name directly maps to the entry point file for the command,” giving the example that a command named index maps to src/index.ts. In practice, this means naming a command isn't only a display decision — it has to correspond to a real file in your extension's source, so it's worth settling the command's name before you scaffold the surrounding code, not after.
If you're naming or describing an AI Extension
Raycast's guide to core concepts of AI Extensions advises against phrasing an extension's internal instructions around a persona, giving the specific example of avoiding “You are a … assistant” framing, since a Raycast user may have several AI Extensions installed at once and persona language doesn't help the AI pick the right one for a given task. That guidance is about how you write the instructions behind the extension, not the name or title fields themselves, but the underlying instinct carries over to naming too: describe what the extension actually does rather than reaching for a generic role label.
Categories affect discoverability too
The Store-preparation guide also covers extension categories, which are case-sensitive and follow Title Case — options include Applications, Communication, Data, Documentation, Design Tools, Developer Tools, Finance, Fun, Media, News, Productivity, Security, System, and Web. Picking the category that actually matches your extension is a small step that affects whether the right users find it browsing the Store, independent of the name itself.
Before you submit
- 01Confirm the extension's name field is short, lowercase, and URL compatible, since it becomes part of the Store link directly.
- 02Write the title field using Apple Style Guide capitalization, favoring a noun that makes the extension's purpose clear at a glance.
- 03Check that command titles follow a <verb> <noun> or <noun> structure, skip articles, and say more than just the service name.
- 04Add a subtitle only where it supplies context the title doesn't already give — drop it if it would nearly repeat the title.
- 05Pick the Store category that actually matches what the extension does.
- 06Re-check Raycast's current Store-preparation guidelines directly before submitting, since official guidance can change independent of this article.
The example names and titles throughout this article are illustrative only. None of them have been checked against the current Raycast Store for naming or availability conflicts — verify a real candidate directly against Raycast's current guidelines and the live Store before you submit.
Name it for two audiences: the Store link, and the person reading it
A Raycast extension name is really several small decisions — an identifier, a display title, command names tied to real files, and an optional subtitle — each with its own narrow rule. None of them are hard to get right individually. What causes rework is treating them as one decision instead of four, or skipping the current official guidelines because a rule seemed safe to assume. Check the source directly, every time you submit, since it's the only place these rules are guaranteed to be current.
Frequently asked questions
What is the difference between the name and title fields in a Raycast extension?
The name field is a unique identifier used directly in the Store link, so it needs to be short and URL compatible. The title field is the human-readable name shown to users in the Store and in Preferences. They serve two different technical purposes, and it's worth deciding both deliberately rather than letting one default to the other.
Should command titles use verbs or nouns?
Raycast's own guidelines describe command titles as usually following a “<verb> <noun>” structure or standing alone as just a noun — for example “Search Recent Projects” or “Translate.” They also recommend avoiding articles, so “Search Emoji” rather than “Search an Emoji.”
When does a Raycast command need a subtitle?
Only when it adds context the title doesn't already carry — typically the specific app or service a command connects to. Raycast's guidelines are explicit that a subtitle nearly duplicating the title should be left out entirely, and that a subtitle is not the place to write a description.
Does a command's name field have to match a specific file?
Yes, in the sense that it maps directly to your extension's source. Raycast's manifest documentation states that a command's name is its unique id and “directly maps to the entry point file for the command,” giving the example that a command named index maps to src/index.ts.
Where should I check the current Raycast Store submission rules?
Directly on developers.raycast.com, which is Raycast's own source of truth and gets updated independently of any third-party guide, including this one.