find-reviewer
SkillCommunicationFind 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.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the find-reviewer skill
What this skill tells your AI
The instructions your AI receives, as published by mozilla-firefox/firefox in .agents/skills/find-reviewer/SKILL.md and read by ahel’s review.
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
-
Run the reviewer suggester on a representative set of the changed files:
./mach file-info reviewers <file> [<file> ...] -
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).
- Herald group reviewers are the authoritative answer: these are the groups
Phabricator would add automatically, so prefer them. A group marked
-
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 lineOnly use such a group if it appears in this list. (See the rule at the top.)
-
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.
Signals
- GitHub stars
- 13k
- Forks
- 1k
- Last commit
- Sep 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
find-reviewer-mozilla-firefox- Source
- github.com/mozilla-firefox/firefox