| 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:
- Listing text review/draft — name, summary, description.
- 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
- 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.
- 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.
- 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.
- 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.
