Menu
You MUST use this skill when working with HTML, JS, CSS and other front-end code.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Find the right reviewer for a Firefox/Gecko change so the user does not have to. Use this primarily when committing changes, to fill in the `r=` part of the commit message automatically instead of leaving it blank or guessing. Also use it when the user asks directly who should review a patch or what reviewer group to use.
Guide for creating new Android gradle modules in the android-components project.
Use this skill when working with Firefox documentation, including building documentation with `./mach doc`, fixing Sphinx build errors or warnings, modifying existing documentation, or adding new docs.
Use this skill when the user wants to file good-first-bugs in Bugzilla for Firefox. A good-first-bug is a narrow, self-contained, low-risk task scoped so a first-time contributor can land it without deep context. Sources include lint warnings, small typos, dead-code removal, mechanical refactors, docs conversions, or any other small task the user points at. Produces prefilled `enter_bug.cgi` URLs the user clicks to submit. Trigger on phrases like "file a good first bug", "open good first bugs for X", "create a good-first-bug from this".
You MUST use this skill when working with C++, C, Rust code to implement or modify WebIDL interfaces and their native implementations.
You MUST use this skill when working with Firefox's linting infrastructure (mozlint), adding new linters, modifying existing linters, running linters, or dealing with linting issues.
| name | firefox-desktop-frontend |
| description | You MUST use this skill when working with HTML, JS, CSS and other front-end code. |
./mach build was previously run and you have not made any changes to C++ or Rust code (nor rebased past incoming changes to such code), you can use ./mach build faster to skip the compilation and linking steps and only build the front-end code. This can save a lot of time when you're only working on the browser/ or toolkit/ code.toolkit/themes/shared/design-system) wherever possible, to ensure consistent UI and to make it easy to change styles across the board.toolkit/content/widgets/. A storybook instance for these components can be accessed on https://firefoxux.github.io/firefox-desktop-components/. It is fine to use in-development components.margin-inline-start instead of margin-left) for better localization support.<a> for links, <moz-button> or <button> for buttons, etc. This helps accessibility and makes the code easier to understand.let instead of var, and use arrow functions where appropriate.<panel>), tooltips (<tooltip>) and menus (<menupopup>, <menuitem>, <menu> and <menuseparator>). Use these elements when appropriate, as they provide built-in behavior and accessibility features..ftl files). Do not use legacy string systems. Check if strings already exist before creating new ones.browser/ directory is available for use from there - if it must be used, make sure that the toolkit/ code can recover if it is not available.