> ## Documentation Index
> Fetch the complete documentation index at: https://docs.skyvexsoftware.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How we review plugins

> What happens between uploading a plugin version and pilots getting it, and what to do when a version is sent back.

Every plugin version, [public or private](/guide/private-plugins), is reviewed by Skyvex Software before it reaches pilots. We review against the [Plugin Guidelines](https://skyvexsoftware.com/legal/plugin-guidelines), a short, versioned list of rules that's part of the [Plugin Terms](https://skyvexsoftware.com/legal/plugin-terms).

## From upload to pilots

<Steps>
  <Step title="Upload">
    Publish a version from the Developer centre (**Publish a version**) or with an API token (`plugin:upload`). The version number must be newer than your latest, and every version needs a What's new: type it in the Developer centre when you publish, or send it with an API token upload (the `changelog` field, `SKYVEX_WHATS_NEW` with `pnpm bundle`). An upload without one waits as a **draft** until you add a What's new in the Developer centre and submit it. See [The Developer centre](/sdk/developer-centre).
  </Step>

  <Step title="In review">
    The version waits for a person, usually within 2 working days. We use automated and AI-assisted checks and systems to help keep review times down. You can withdraw it while it waits; the same version number can then be uploaded again.
  </Step>

  <Step title="Approved or sent back">
    Approved versions follow the release mode you chose when you uploaded. **Automatic** goes out straight away. **Manual** waits for you to press **Release** on the version. A version sent back comes with a note and the guidelines it doesn't meet yet, by email and on the version.
  </Step>

  <Step title="Pilots update">
    Released versions reach pilots on their next update check.
  </Step>
</Steps>

## Screenshots come first

Screenshots belong to the plugin's listing, not to a version. Every plugin, public or private, needs at least 3 complete [screenshot pairs](/sdk/screenshots) (a light and a dark image each) on its listing before a version can be submitted for review. You can upload versions at any time: until the listing has its pairs, each one waits as a draft, even with What's new sent alongside it, and **Submit for review** stays off and says how many pairs are missing. Add them on the Listing tab, then submit the draft. Nothing already out with pilots is affected.

## What we look at

* **What it does matches what it says.** The listing, the What's new and the code agree.
* **The guidelines.** Each one is checked; anything unmet is listed on the verdict with why.
* **The code that runs.** We review the bundle pilots will get. Minified is fine; obfuscated isn't. Source maps with full `sourcesContent` make the review quicker. We check every map against the code it describes, and a version whose maps don't match, or only partly carry `sourcesContent`, always waits for a person. A bundle with no maps is fine; we read the bundle itself. Maps are stripped before publishing unless you set `include_source_maps`.
* **No downloaded or injected code.** A plugin can't fetch and run code, reach into Stratos's own files, or import Stratos internals.

## When a version is sent back

Read the note and the unmet guidelines on the version, fix them, raise the version number and upload again. A rejected version can also be replaced by uploading the same number again. Nothing about a rejection counts against you beyond your review history, which [verification](/sdk/verified-developers) looks at.

## Private plugins

Private plugins are reviewed the same way as public ones: the same automated checks, the same guidelines and the same person at Skyvex Software. Being private only changes who can use the plugin, not how it's reviewed. A private plugin needs its listing screenshots before a version can be submitted, too.

## Updates that don't wait in the queue

Plugins Skyvex Software builds go out without the queue when the automated checks pass. Some long-standing developers' updates may also be released without waiting in the queue, once we've reviewed their plugin. That never applies to a plugin's first version, to its first version after it becomes public, or to a version our automated checks flag: those always wait for a person.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.