# Addons Developer Suite
A set of four [Claude Skills](https://docs.claude.com) for Firefox add-on
development: policy compliance, manifest.json correctness, data-collection
taxonomy, and AMO submission paperwork.
> [!IMPORTANT]
> **This suite is unofficial.** It is not built, reviewed, or endorsed by
> Mozilla, and nothing in it is affiliated with the Mozilla add-ons team or
> addons.mozilla.org (AMO). Every skill here is a heuristic aid grounded in
> Mozilla's *published* documentation at the time it was written — it is not
> a substitute for reading the actual policies, running Mozilla's own
> tooling (`web-ext lint`), or going through AMO's real review process. **A
> clean result from any skill in this suite is not a guarantee that Mozilla
> will approve an add-on** — only Mozilla's own reviewers can determine that.
## What's in here
| Skill | What it does |
|---|---|
| [`firefox-addon-policy-check`](./firefox-addon-policy-check) | Scans an extension's source for patterns that commonly violate Mozilla's [Add-on Policies](https://extensionworkshop.com/documentation/publish/add-on-policies/) — permission scope, remote code loading, CSP relaxation, data collection & consent, monetization rules (ads, affiliate links, crypto miners), source/obfuscation requirements, and "No Surprises" feature disclosure. |
| [`firefox-addon-manifest-scaffold`](./firefox-addon-manifest-scaffold) | Scaffolds a new `manifest.json`, or lints an existing one for technical/schema problems — Manifest V2 vs. V3 shape mismatches, missing `browser_specific_settings.gecko.id`, invalid `content_security_policy`/`web_accessible_resources` shape, `action` vs. `browser_action` mistakes. |
| [`firefox-addon-data-taxonomy`](./firefox-addon-data-taxonomy) | Helps classify what data an add-on collects/transmits into Mozilla's `data_collection_permissions` taxonomy, decide required vs. optional, and drafts the manifest snippet plus a compliant custom consent page for pre-Firefox-140 support. |
| [`firefox-addon-amo-submission`](./firefox-addon-amo-submission) | Drafts and reviews the non-code parts of an AMO submission — listing name/summary/description, and "Notes for Reviewers" (testing credentials, source/build reproduction steps, third-party library source-link table). |
The four are designed to hand off to each other: the policy checker's data-
transmission findings feed the taxonomy helper, the taxonomy helper's output
feeds the manifest scaffolder, and the submission helper reuses findings
from all three when drafting reviewer notes and listing copy.
## Installing a skill
Each skill directory is also packaged as a ready-to-install `<name>.skill`
file at the repo root. In a Claude app that supports skills, opening or
uploading the `.skill` file shows a **Save skill** button that installs it.
To install manually instead, copy the skill's directory (the one containing
`SKILL.md`) into wherever your Claude setup loads skills from.
## Repo layout
Each skill is self-contained:
```
<skill-name>/
├── SKILL.md — triggering description + instructions
├── scripts/ — the actual scanner/linter (Python, no dependencies beyond the standard library)
└── references/ — policy/schema/taxonomy text the skill cites from, so it can quote
Mozilla's actual wording instead of paraphrasing from memory
```
## Keeping this current
Mozilla revises the Add-on Policies, the manifest.json schema, and the data
collection taxonomy over time. The `references/` files in each skill were
accurate as of when they were written, sourced directly from
[extensionworkshop.com](https://extensionworkshop.com/documentation/publish/add-on-policies/)
and [MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json).
If Mozilla changes something these skills check for, the fix is to update the
relevant `references/*.md` file (and, if the check itself changed shape, the
matching script) — not to trust the skills over the live documentation.
## License
MPL-2.0 — see [`LICENSE`](./LICENSE).