firefox-addon-amo-submission

name

firefox-addon-amo-submission

description

Drafts and reviews the non-code parts of an addons.mozilla.org (AMO) submission for a Firefox extension -- the listing name/summary/description (checked against Mozilla's "No Surprises" and Content policy clauses), and the "Notes for Reviewers" text (testing instructions/credentials, source-code build-reproduction steps, and a third-party library source-link table). Use this whenever someone is about to submit or resubmit a Firefox extension to AMO, needs to write or fix their extension's store listing, is being asked by a reviewer for testing steps/source code/library links, or wants help with "notes for reviewers." Part of a Firefox add-on suite alongside firefox-addon-policy-check (code-level policy scan), firefox-addon-manifest-scaffold (manifest.json), and firefox-addon-data-taxonomy (data collection consent). UNOFFICIAL, not built or endorsed by Mozilla, does not submit anything on the user's behalf, and drafting clean submission paperwork here is no guarantee AMO will accept the add-on.

Firefox AMO Submission Helper (unofficial)

Say this up front

This drafts the paperwork around a submission — the listing copy and the reviewer notes — based on Mozilla's published policies. It doesn't file anything with AMO, doesn't see the actual review queue, and can't guarantee acceptance; only Mozilla's review process decides that. Say this before drafting and repeat it when handing over the final draft.

What this skill produces

Two deliverables, usually both:

1. Listing text review/draft — name, summary, description.
2. Notes for Reviewers draft — testing steps, source/build instructions, and a third-party library table.

Listing text

Get (or write, if the user wants a first draft) the add-on's name, summary, and description, then check it against references/submission-checklist.md §"Listing text": does it name every feature that isn't obviously implied by the description (per "No Surprises"), does "Firefox" in the name follow the <Add-on name> for Firefox pattern, is any required payment disclosed, is a fork clearly distinguished from its original, does the add-on do more than just point at some other site/app/add-on. Flag gaps concretely — "the description doesn't mention the new-tab override" is useful, "make sure it's compliant" is not.

If this add-on has already been through firefox-addon-policy-check, reuse its findings rather than re-deriving them — e.g. a flagged chrome_settings_overrides change needs to show up in the listing text, not just get fixed in code.

Notes for Reviewers

1. Testing info. Ask whether any feature needs an account/login. If yes, the notes need working test credentials — a reviewer who can't log in generally means a rejection, not a benefit of the doubt.
2. Source & build. If the shipped code is minified/bundled/transpiled at all, draft the human-readable-source + build-reproduction section: exact tool versions, the build command, where the output lands, and confirmation that dependencies come from official registries or are included in the submitted package. See references/submission-checklist.md for what reviewers specifically check for here.
3. Third-party libraries. Run:

   python3 <skill_dir>/scripts/scan_third_party_libs.py <extension_root> --json
   

   This surfaces npm dependencies and vendored files that look like known libraries, with a guessed version where detectable. It does not produce the actual release-tag source link Mozilla requires — that needs a human to go find the real tagged file on the library's official repo (never a CDN link, never master/main). Turn the script's output into a table with columns: Library | Version | Where bundled | Source link (TODO: fill in for anything the script couldn't nail down), and be explicit with the user about which rows still need their input.
4. If this is a correction/resubmission, remind the user (per the checklist) to keep the diff scoped to what was actually requested.

Handing off

Close with the disclaimer again, and mention: this doesn't replace actually reading review feedback if/when it comes back, and the third-party-library table specifically still needs the user's own verification before it's submitted — don't let a mostly-filled-in table read as fully done.