find-reviewer

SkillCommunication

Lets your agent find the right reviewer for a Firefox code change and fill in the review line of the commit message.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the find-reviewer skill

About this capability

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

What this skill tells your AI

The instructions your AI receives, as published by browserworks/waterfox-android 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

  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.

Signals

GitHub stars
356
Forks
31
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
find-reviewer
Source
github.com/browserworks/waterfox-android