Review Process

Learn how plugin submissions move through an initial scan and human review.

Starting July 21, 2026, all new plugin submissions and version updates must follow the review process and criteria in this section.

Why the Review Process Is Changing

As AI coding tools become more widely available, more people can participate in Eagle plugin development. We welcome developers turning ideas into genuinely useful plugins. At the same time, the increase in submissions has brought more work that is unverified, incomplete, or clearly below release quality.

Some submissions are assembled from AI-generated code and uploaded without the developer fully reading the code, understanding how the plugin works, or knowing which services it connects to, what data it handles, or which files it changes. These submissions significantly increase review workload and can introduce security vulnerabilities, user-data risks, and destructive behavior.

We do not prohibit responsible use of AI-assisted development. However, submitting a plugin assembled from AI-generated code that the developer has not understood, reviewed, and tested is strictly prohibited. AI tools do not replace developer responsibility and are not an excuse for security issues, data loss, or broken functionality.

Developers must understand the code and dependencies they submit, confirm that actual behavior matches the store listing, and test the final package. If a developer cannot explain the plugin's core logic, external connections, data handling, file changes, or dependency sources, the submission may not pass review.

We expect every developer to take responsibility for their plugin, and Eagle must take responsibility for the users who install it. Based on this principle, review has two stages: an initial scan followed by human review.

Process Overview

Submit plugin
   │
   ▼
Stage 1: Initial scan
Release configuration / Copy / Visuals / Security and privacy / Package / File safety
   │
   ├─ Does not pass ─→ Receive required changes ─→ Revise and resubmit
   │
   └─ Passes
        │
        ▼
Stage 2: Human review
Functionality / Usability / Policy compliance / Context-dependent issues
        │
        ├─ Does not pass ─→ Receive required changes ─→ Revise and resubmit
        │
        └─ Passes ─→ Published

Stage 1: Initial Scan

After submission, automated tools assist with an initial scan of requirements that can be verified consistently. A submission moves to human review only after passing this stage. The scan covers:

• release configuration and whether the package can be safely extracted and inspected;

• completeness and accuracy of store listing copy and required disclosures;

• whether icons and covers are complete, legible, and relevant;

• undisclosed dangerous behavior, data transfers, or privacy risks;

• sensitive data, development artifacts, or unnecessary package contents;

• malware and other unsafe files.

If clear evidence identifies a problem that must be fixed, the submission ends at this stage and the developer receives correction guidance as soon as possible. Only submissions that pass the initial scan proceed to human review.

Passing this stage means the submission is ready for human review. It does not mean the plugin has been approved. See Review Criteria for the complete requirements.

Stage 2: Human Review

Human reviewers evaluate matters that require functional testing or context, including:

• whether the plugin installs, starts, and completes its main functionality;

• how it handles cancellation, invalid input, and error states;

• whether changes to Eagle data or local files match the description and user expectations;

• whether flows requiring sign-in, external services, or third-party applications can be completed;

• whether the developer understands important plugin behavior and provides necessary review information;

• compliance with the Developer Policies and any issue that requires contextual judgment.

Human review may revisit items that require further judgment after the first stage. Because plugin functionality and risk vary, the exact test scope is adjusted to each submission.

How Decisions Are Made

A submission is blocked only when verifiable evidence shows a specific rule violation that requires developer action. Personal aesthetic preference, minor language issues, optional quality improvements, or unconfirmed concerns do not independently justify rejection.

When a submission does not pass, we describe objective issues the developer can verify and provide actionable correction guidance. Internal tools, detection methods, and implementation details are not developer-facing requirements.

See Review Results and Resubmission for what happens after a decision.