Skip to main content
Every plugin version, public or private, is reviewed by Skyvex Software before it reaches pilots. We review against the Plugin Guidelines, a short, versioned list of rules that’s part of the Plugin Terms.

​
From upload to pilots

1

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.
2

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.
3

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.
4

Pilots update

Released versions reach pilots on their next update check.

​
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 (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 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.