Skip to main content

find-reviewer

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.

Jump to install

Source facts

Repository
mozilla-firefox/firefox
Last source activity
July 10, 2026 at 23:04
Detected SKILL.md language
English
Stars
12,825
Forks
1,400

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
find-reviewer
description
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.
allowed-tools
["Bash(./mach file-info:*)"]
## NEVER invent a reviewer name A reviewer or group name must be used **exactly** as it appears in the tooling's output. NEVER abbreviate, shorten, guess, or make up a name (for example, writing `r=#build` when the real group is `r=#firefox-build-system-reviewers`). `moz-phab` rejects a submission containing an unknown reviewer (`#madeup-reviewer-group is not a valid reviewer's name`), forcing the user to amend the commit and re-submit. For a name that did not come straight from the Herald output, do not use it unless it appears in `./mach file-info reviewer-groups`. ## Overview When committing a Firefox/Gecko change, the `r=` reviewer should be filled in for the user, not left to them. This skill determines it from the files the change touches: the primary signal is the set of group reviewers that Phabricator's Herald rules would automatically attach; when no rule matches, it falls back to the individuals and groups that reviewed recent patches to those files. Use it whenever you are about to write a commit message for a change, and also when the user asks directly who should review something. ## Workflow 1. **Run the reviewer suggester** on a representative set of the changed files: ``` ./mach file-info reviewers <file> [<file> ...] ``` 2. **Interpret the output.** - **Herald group reviewers** are the authoritative answer: these are the groups Phabricator would add automatically, so prefer them. A group marked `(blocking)` must approve before landing. - When it prints **"No Herald group reviewers matched"**, it lists **recent reviewers from version control history** instead. Treat these as candidates, not certainties: rank by the counts shown, and discount groups that only appear because of tree-wide mechanical commits (mass reformats, lint sweeps) that are unrelated to the change. - If neither yields a good answer, fall back to the file's Bugzilla component (`./mach file-info bugzilla-component <file>`) and its matching reviewer group, after validating the name (step 3). 3. **Validate names whose origin is not the Herald output.** Herald group reviewers come straight from the current reviewer-selector data, so they are already valid -- do not re-check them. Confirm the exact spelling only of a group that came from somewhere else: one the user supplied, or one taken from version control history (which may have been renamed or retired since that commit landed): ``` ./mach file-info reviewer-groups # one group name per line ``` Only use such a group if it appears in this list. (See the rule at the top.) 4. **Use it in the commit message.** Groups take a `#` prefix (`r=#firefox-build-system-reviewers`); individuals take none (`r=somebody`). Append `!` to require a reviewer's approval before landing (`r=#firefox-build-system-reviewers!`); the command marks such reviewers `(blocking)`. When the choice is ambiguous (several plausible groups, or only noisy history), state the pick and the runners-up so the user can override. ## Notes - This skill suggests reviewers; it does not submit anything to Phabricator.
View on GitHub