find-reviewer

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.