> 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/package-contents.md).

# Package Contents

The submitted `.eagleplugin` must be a clean release package containing only files required at runtime. Review inventories content that may be sensitive, development-only, unnecessary, nested, or binary, then evaluates it in context.

An item being reviewed does not mean it is automatically prohibited. A plugin may legitimately need a native binary or runtime dependency, but the developer must be able to explain its source, purpose, and necessity.

## Exclude Development Directories

The final package should not normally contain unrelated version-control, editor, virtual-environment, or cache directories, including:

* `.git/`, `.svn/`, `.hg/`, `.bzr/`;
* `.idea/`, `.vscode/`;
* `__pycache__/`, `.pytest_cache/`;
* `.venv/`, `venv/`.

Do not package the entire project directory unchanged. If `node_modules/` or another dependency directory is required at runtime, retain only what the release needs. Remove unused development dependencies and duplicate packages from built releases.

## Remove Sensitive Data

The package must not contain real credentials or private keys. Check especially for:

* `.env` files and variants;
* `.pem`, `.key`, `.p12`, and `.pfx` keys or certificates;
* `credentials.json` and `secrets.json`;
* `.npmrc` files containing tokens or private registry credentials;
* test accounts, personal data, internal URLs, or development databases.

If a secret has been packaged or exposed, deleting the file is not enough. Revoke and rotate the affected secret or credential immediately.

## Remove Unnecessary Files

Exclude system and temporary files that do not affect runtime, such as:

* `.DS_Store`, `Thumbs.db`, `desktop.ini`;
* `.log`, `.tmp`, `.swp`, `.swo`;
* test output, debug logs, draft screenshots, and local caches;
* duplicate `dist/` directories, old builds, or redundant source and release artifacts.

A focused package makes it easier to verify what users will install and reduces accidental disclosure and supply-chain risk.

## Avoid Nested Archives and Duplicate Packaging

Do not include unrelated `.zip`, `.rar`, `.7z`, `.tar`, `.tgz`, `.gz`, `.dmg`, or `.iso` files inside the `.eagleplugin`.

If an archive is required for plugin functionality, explain its contents, source, and use in the review notes. Bundled source archives, previous installers, backups, or another complete plugin obscure the actual release scope and may block the submission.

## Binary Files

Files such as `.exe`, `.dll`, `.msi`, `.dylib`, `.so`, `.app`, `.pkg`, and `.bin` receive additional review, but binary format alone is not a rejection reason.

When a binary component is required:

* it must directly support the stated plugin functionality;
* it must come from a trusted source and be redistributable by the developer;
* supported platforms and architectures must be disclosed;
* it must not perform undisclosed installation, downloads, or system changes;
* unrelated platforms and obsolete duplicate versions should not be bundled.

## Common Reasons a Submission Does Not Pass

* The package includes version-control directories, editor settings, or virtual environments.
* An `.env`, private key, or credential file is bundled.
* Nested source archives, previous installers, or duplicate build output are included.
* Large amounts of unrelated logs, caches, test files, or system files are present.
* A binary's source or purpose cannot be explained, or it performs undisclosed system operations.

Build from a fresh release directory and inspect an extracted copy before submission to confirm that it contains only what users need to install.