firefox-addon-amo-submission

# 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: ```bash 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.