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.
1---2name: firefox-addon-amo-submission3description: 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.4---56# Firefox AMO Submission Helper (unofficial)78## Say this up front910This drafts the paperwork around a submission — the listing copy and the11reviewer notes — based on Mozilla's published policies. It doesn't file12anything with AMO, doesn't see the actual review queue, and can't guarantee13acceptance; only Mozilla's review process decides that. Say this before14drafting and repeat it when handing over the final draft.1516## What this skill produces1718Two deliverables, usually both:19201. **Listing text review/draft** — name, summary, description.212. **Notes for Reviewers draft** — testing steps, source/build instructions,22 and a third-party library table.2324## Listing text2526Get (or write, if the user wants a first draft) the add-on's name, summary,27and description, then check it against `references/submission-checklist.md`28§"Listing text": does it name every feature that isn't obviously implied by29the description (per "No Surprises"), does "Firefox" in the name follow the30`<Add-on name> for Firefox` pattern, is any required payment disclosed, is a31fork clearly distinguished from its original, does the add-on do more than32just point at some other site/app/add-on. Flag gaps concretely — "the33description doesn't mention the new-tab override" is useful, "make sure it's34compliant" is not.3536If this add-on has already been through `firefox-addon-policy-check`, reuse37its findings rather than re-deriving them — e.g. a flagged38`chrome_settings_overrides` change needs to show up in the listing text, not39just get fixed in code.4041## Notes for Reviewers42431. **Testing info.** Ask whether any feature needs an account/login. If yes,44 the notes need working test credentials — a reviewer who can't log in45 generally means a rejection, not a benefit of the doubt.462. **Source & build.** If the shipped code is minified/bundled/transpiled at47 all, draft the human-readable-source + build-reproduction section: exact48 tool versions, the build command, where the output lands, and confirmation49 that dependencies come from official registries or are included in the50 submitted package. See `references/submission-checklist.md` for what51 reviewers specifically check for here.523. **Third-party libraries.** Run:53 ```bash54 python3 <skill_dir>/scripts/scan_third_party_libs.py <extension_root> --json55 ```56 This surfaces npm dependencies and vendored files that look like known57 libraries, with a guessed version where detectable. It does **not**58 produce the actual release-tag source link Mozilla requires — that needs59 a human to go find the real tagged file on the library's official repo60 (never a CDN link, never `master`/`main`). Turn the script's output into a61 table with columns: Library | Version | Where bundled | Source link62 (`TODO: fill in` for anything the script couldn't nail down), and be63 explicit with the user about which rows still need their input.644. **If this is a correction/resubmission**, remind the user (per the65 checklist) to keep the diff scoped to what was actually requested.6667## Handing off6869Close with the disclaimer again, and mention: this doesn't replace actually70reading review feedback if/when it comes back, and the third-party-library71table specifically still needs the user's own verification before it's72submitted — don't let a mostly-filled-in table read as fully done.
mozilla