raycast-store-publishing

name: raycast-store-publishing description: "Package and submit a Raycast extension to the Raycast Store — manifest metadata, icon and screenshots, changelog/versioning, the publish flow (PR to the extensions repo), and review-guideline readiness. USE WHEN preparing to publish, updating, or passing review for a Raycast extension. Defer exact requirements to developers.raycast.com." cluster: raycast version: 1.0.0

Raycast Store Publishing

Getting an extension into the Raycast Store is a metadata + review exercise on top of a working build (raycast-core). This spoke is the checklist; confirm current specifics at developers.raycast.com.

Pre-submission checklist (manifest & assets)

• Identity: clear title, a concise benefit-led description, an author, and accurate categories.
• Icon: 512×512 PNG (light + dark friendly); follow Raycast's icon conventions.
• Commands: every commands[] entry has a meaningful title and subtitle; no dead commands.
• Screenshots: real, representative captures at the required dimensions (use Raycast's window-capture); first screenshot is the hero.
• Changelog: a CHANGELOG.md entry for this version; bump the version sensibly.
• README: what it does, setup (API keys via preferences), and any caveats.

The publish flow

1. ray build clean (typecheck + lint pass; no console noise, no secrets committed).
2. Run the publish command (npm run publish / ray publish) — it opens a pull request to the raycastapp/extensions repository.
3. Raycast's automated checks + human review run on the PR; respond to review feedback.
4. On merge, the extension goes live in the Store.

Passing review (common rejections)

• Secrets in code → move to preferences (password type), read via getPreferenceValues.
• Poor empty/loading/error states → handle isLoading, empty List, and failures with toasts.
• Unclear actions → every list item needs a sensible primary Action and ActionPanel.
• Naming/branding → don't imply official affiliation; follow trademark/naming rules.
• Destructive actions without confirmation → wrap in confirmAlert.
• Performance → don't block the UI; use the @raycast/utils data hooks.

Updating

• Same flow for updates: edit, add a CHANGELOG entry, bump version, re-run publish (new PR).
• AI extensions: keep tools[] descriptions and evals current → raycast-ai-extensions.

Guardrails

• No secrets in the repo — preferences only.
• Real screenshots + 512px icon + accurate categories before submitting.
• Handle loading/empty/error states and confirm destructive actions (review will catch these).
• Treat the Store review guidelines at developers.raycast.com as authoritative; this is a readiness checklist, not the rulebook.