> For the complete documentation index, see [llms.txt](https://developer.eagle.cool/plugin-api/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.eagle.cool/plugin-api/plugin-review/criteria/configuration-and-reviewability.md).

# Release Configuration and Reviewability

Every submission must open safely and include the basic configuration and information required for review. A package that cannot be extracted, lacks required settings, or is still configured as a development build will block the current submission.

## Submit a Valid Package

Use Eagle to create the `.eagleplugin` file and confirm that:

* the file opens and extracts completely without corruption;
* the archive contains no duplicate paths, unsafe links, or paths that could write outside the plugin directory;
* it is the final release package, not another archive format with a renamed extension;
* it still installs correctly after being downloaded or moved.

An invalid, corrupted, or unsafe archive cannot proceed to further review. Rebuild it from a clean release directory instead of manually modifying an existing `.eagleplugin` file.

## Place `manifest.json` in the Plugin Root

The release must meet these minimum requirements:

* `manifest.json` exists in the plugin root;
* the file contains a valid JSON object;
* `id` and `name` are non-empty strings;
* `devTools` is not set to `true`.

All other fields must match the plugin type and actual behavior. See [manifest.json Configuration](/plugin-api/tutorial/manifest.md) for the complete format.

## Submit a Release Build

The release must not enable developer tools or depend on paths, services, or environment variables available only on the developer's computer. Install the packaged file before submission and verify that it runs without the original project directory.

If the plugin supports only certain operating systems, Eagle versions, file formats, or companion software, disclose that limitation in the store introduction. A limitation is not automatically disqualifying; failing to disclose one that prevents core use is a problem.

## Provide Reproducible Review Instructions

No additional review document is normally needed when the plugin works without special setup. Provide steps in the submission notes or a `README` in the plugin root when the plugin requires:

* sign-in, an API token, a license key, or a review account;
* a server, third-party application, or local integration tool;
* system configuration changes or additional permissions;
* specific test files, data formats, or an essential sequence of actions;
* payment, a subscription, or a trial to complete the core flow.

The instructions must let a reviewer reproduce the main workflow. Review accounts must remain valid during review. Provide test credentials through the submission page; do not include real credentials, secrets, or user data in the package.

## Common Reasons a Submission Does Not Pass

* `manifest.json` is missing from the plugin root or cannot be parsed.
* `id` or `name` has no valid value.
* `devTools` is set to `true` in the release.
* The `.eagleplugin` file is corrupted or cannot be safely extracted.
* Core functionality requires authentication or a special environment, but no usable review method is provided.

After correcting these issues, rebuild the package and test a fresh installation before resubmitting.