| name | uplift-request |
| description | Help prepare a Firefox uplift approval request (Beta, Release, and/or ESR) by checking whether patches are already on the bug, auditing sanitization once for sec-* bugs, and drafting the approval comment per https://wiki.mozilla.org/Release_Management/Uplift_rules. Use after a fix is ready and needs to ride into a stabilization branch. May or may not follow sec-approval (sec-moderate typically skips sec-approval but may still need uplift). |
| argument-hint | [bug-id] [path-to-bug-report] [--beta] [--release] [--esr NN] |
| allowed-tools | ["Bash(git:*)","Bash(jj:*)","Bash(searchfox-cli:*)","Bash(bmo-to-md:*)","Bash(moz-phab:*)","Bash(python3:*)","Read","Grep","Glob","AskUserQuestion","WebFetch","Write"] |
Uplift Request Skill
Drafts a Bugzilla uplift-approval comment for Firefox Beta, Release, and/or
ESR, following the
Uplift rules.
Dependencies and Bugzilla API key setup live in
README.md. Point the user there if bmo-to-md or
bmo-uplift-request --check-auth fails.
This skill may run standalone (e.g. sec-moderate, non-security regressions) or
after sec-approval has already been filed. The sanitization audit for
sec-* bugs runs exactly once, early in the flow, and all later steps
trust that result.
The Bugzilla API key config is shared with the sec-approval skill — if
that works, this will too. Never read or print the key; use
python3 .claude/skills/uplift-request/bmo-uplift-request --check-auth
to test availability.
Arguments: $0
Parse:
- The first all-digit token with 6 or more digits and not immediately
following
--esr is the bug ID. The 6-digit floor avoids collision
with ESR version numbers (--esr 140), which are 2–3 digits.
- Any token containing
/ is the bug report path (a folder of markdown
written by bmo-to-md).
--beta, --release, and --esr NN select target channels; multiple are
allowed. If none are supplied, ask after Step 1.
All arguments are optional.
Step 1 — Gather context
Retrieve the bug
- sec-* or otherwise restricted:
mcp__moz__get_bugzilla_bug will fail.
Use the same priority order as sec-approval:
- If the user supplied a bug-report path, read
summary.md / bug-<id>.md
from that folder.
- Otherwise run
bmo-to-md -o /tmp/bug-<id> -a <bug_id> (requires a
Bugzilla API key — check with the --check-auth command above).
- Otherwise ask the user.
- public bugs: prefer
mcp__moz__get_bugzilla_bug.
Collect: component, keywords, severity, sec-* level (if any), existing
status-firefoxNN / tracking-firefoxNN flags, regressor bug if known, and
any prior uplift comments.
Inspect local commits
jj --version 2>/dev/null && echo "jj" || echo "git"
git:
git log --oneline origin/main..HEAD
git log origin/main..HEAD --format=%B
git diff --stat origin/main..HEAD
git diff origin/main..HEAD -- <file>
jj:
jj log -T builtin_log_detailed -r 'trunk()..@'
jj diff --stat -r 'trunk()..@'
jj diff -r 'trunk()..@' <file>
Record: commit messages, every Differential Revision: .../D<N> trailer, and
the full diff.
Current release context
WebFetch: https://whattrainisitnow.com/calendar/
Extract current Nightly, Beta, Release, and live ESR versions. Also read the
local tree version if available: cat config/milestone.txt.
Step 2 — Determine target channel(s)
If the user did not pass --beta / --release / --esr NN, ask with a
single AskUserQuestion (multiSelect) using concrete versions from the
calendar (e.g. "Beta 149", "ESR 140", "ESR 128"). Only offer ESR versions
that are currently supported.
A single block may cover several channels when they share the same patch.
See Step 6 for the block-grouping rule (one block per distinct patch
variant, not per channel).
Step 3 — Check whether patches are on the bug
Goal: know which of the four scenarios below we're in, so Step 4 can audit
exactly once.
-
List attachments (the script never prints the API key):
python3 .claude/skills/uplift-request/bmo-uplift-request <bug_id> --list
This prints each active Phabricator and raw-patch (text/plain)
attachment with its ID, Phabricator revision (if any), summary, and
current flags.
-
Match each local commit against the attachments:
- Strong — Phabricator:
Differential Revision: .../D<N> trailer
matches an attachment whose summary or (decoded) data contains D<N>.
- Strong — raw patch: fetch the
text/plain attachment content and
compare the first few diff --git hunk headers against the local diff.
Matching file paths + identical hunk headers is a strong match;
identical bodies is conclusive.
- Weak: title/summary overlap only — treat as "possible", confirm with
the user before trusting.
-
Record the scenario (sec-* cases only — non-sec bugs skip Step 4):
- A. No matching attachments. Local has the patches.
→ User hasn't submitted. Audit local commits.
- B. Same as A, but the user only wants the form drafted (no
submission). → Audit local commits.
- C. Attachments match local. → Audit local commits (same content).
- D. Attachments exist but diverge from local, or there are no local
commits.
→ Audit what we can fetch: raw-patch attachment content and/or local
commits if present. For Phabricator attachments with no local match we
cannot pull the diff without Phab auth — flag that to the user and ask
them to confirm the attached patches were sanitized.
Present the outcome as a short table before branching.
Step 4 — Sanitization audit (sec-* only, runs once)
Skip this entire step for non-sec bugs.
Run Phase 1 — Compliance Audit from the sec-approval skill
(commit messages, inline comments, identifiers, tests, Try server,
obfuscation). Do not duplicate the audit text here — follow the checks in
.claude/skills/sec-approval/SKILL.md Phase 1 and present the same
PASS/FAIL table.
Inputs, per scenario from Step 3:
| Scenario | What to audit |
|---|
| A, B | Local commits (and diffs). |
| C | Local commits (same content as the attachments). |
| D | Local commits if any; raw-patch attachment content; for Phabricator-only, ask user. |
Outcome:
- All PASS → set an internal flag
sanitization_ok = true. Steps 5 and 6
proceed without re-auditing.
- Any FAIL → block. Present the specific violations with suggested fixes
and ask the user to resolve them. After fixes, re-run this step. If
attachments on the bug already contain unsanitized content (scenario C/D
where the audit fails), remind the user they must update both local and
re-submit the sanitized version (Step 5) before continuing.
No downstream step runs the audit again.
Step 5 — Submit path (only if patches aren't on the bug, or need re-submission)
Triggers:
- Scenario A: user asks Claude to submit.
- Scenario D after a re-sanitization.
Two submit paths. Prefer 5a (moz-phab uplift) unless the user has a
concrete reason to fall back to raw-patch attachments. Either path is
user-visible and hard-to-reverse — always confirm before running.
Scenario B (user submits themselves later) — skip this step; just tell
the user which commands to run when they are ready.
5a — moz-phab uplift (preferred)
The moz-phab uplift flow creates a new Phabricator revision per target
train, and a bot automatically adds Release Managers as reviewers when
the lando uplift form is completed. Wiki:
https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift#Requesting_Uplift_using_moz-phab
On path 5a the Step 7 answer file is not posted as a BMO comment —
instead the user pastes its contents into the lando uplift form (URL
printed at the end of each moz-phab uplift run). Skip Step 8 in that
case.
Preflight (once per run):
moz-phab uplift --list-trains confirms train names (they begin
with firefox- and do not always match the branch name; e.g.
firefox-esr140, firefox-esr115, firefox-beta,
firefox-release).- Check whether each target branch already has the fix. A Nightly
library uprev (libaom/libvpx/dav1d/etc.) often carries the upstream
fix across merge day — e.g. once Beta rotates forward, Beta may
already contain the patched file. Confirm before committing any
uplift work:
git fetch upstream <target-branch>
git show upstream/<target-branch>:path/to/file \
| grep -c '<pre-fix-token>'
git log --oneline upstream/<target-branch> -- path/to/file | head
If the fix is already present, skip that channel entirely and tell
the user — the corresponding approval-mozilla-*? flag on any
pre-existing raw-patch attachment is now moot.
Per-channel flow: for each channel that still needs the patch,
- Ensure the worktree is on
mozilla-firefox/firefox and the target
tip is fetched (upstream/beta, upstream/release,
upstream/esrNN).
- Stash irrelevant working-tree modifications so only the uplift diff
is present:
git stash push -m "uplift-tmp" -- <paths-to-stash>
- Create a local branch off the target tip and commit the uplift
patch. Cherry-pick when the same diff applies verbatim; otherwise
git apply the prepared .patch file:
git checkout -b bug-<bug_id>-<channel> upstream/<target-branch>
git cherry-pick <uplift-commit>
git apply /path/to/bug<bug_id>-uplift-<channel>.patch
git add <paths> && git commit -m "<sanitized subject>"
- Sanitized commit subject for sec-* bugs. The subject
propagates into the Phabricator revision title, bot notifications,
and CI logs — keep it maximally generic. Good:
Bug <id> - Cherry-pick <library> fix, Bug <id> - Backport <library> patch.
Avoid words that hint at the bug class: thread-safety, race,
bounds, overflow, use-after-free, free, UAF, heap, or specific
symbol/file names (grain_synthesis.c, add_film_grain_run,
etc.). Strip the commit body entirely.
- Default to
--no-wip (Needs Review on creation). Do not use
moz-phab's WIP/Changes-Planned default for uplifts. Going
--no-wip from the start is what gets the BMO
approval-mozilla-<train>? flag set automatically, because BMO's
Phab→BMO sync only runs the flag-creation block when
is_new=true and the revision is in needs-review (not
changes-planned) at the moment of attachment creation. WIP
submissions miss that window and the flag has to be set
manually afterwards. WIP would only be "safer" if you wanted to
eyeball the Phab revision before Release Managers see it —
but Release Managers aren't added as blocking reviewers until
the lando form is submitted, so WIP buys nothing in practice
and costs the auto-flag.
- Run
moz-phab uplift --train <train> --no-wip <base-rev> <tip-rev>:
moz-phab uplift --train firefox-esr140 --no-wip upstream/esr140 HEAD
--yes skips interactive confirmation; --no-rebase is useful
when the patch has already been adapted for the target branch.
- Open the lando URL printed at the end of the run
(
https://lando.moz.tools/uplift/request/?revisions=<rev-id>) and
paste the Step 7 answer file into the nine-question uplift form —
completing the form is what actually requests #release-managers
review and posts the questionnaire to the bug. Do this for each
per-channel revision.
- After the user submits the lando form, verify the approval
flag on the resulting BMO attachment. With
--no-wip
submissions the flag should already be present. Confirm:
python3 .claude/skills/uplift-request/bmo-uplift-request \
<bug_id> --list
For each per-channel attachment, look for
approval-mozilla-<train>? (e.g. approval-mozilla-esr140?
after a firefox-esr140 submission). If it's there, done.
If it's missing (which can still happen — see the WIP fallback
in step 9), set it manually using the script's flag-only mode:
python3 .claude/skills/uplift-request/bmo-uplift-request \
<bug_id> --attachment <id> --<channel>
No comment_file argument means no comment in the PUT, so the
manual fix won't duplicate the lando-posted comment. Map
attachment ID → channel by reading the lando-created
attachments' file_name field, which has the form
phabricator-D<rev>-url.txt; cross-reference each D-rev against
the moz-phab output you captured at submission.
- WIP fallback (legacy / corner case). If for some reason a
revision was already submitted WIP and you need to flip it to
Needs Review, the local commit must first carry a
Differential Revision: https://phabricator.services.mozilla.com/D<id>
trailer so moz-phab updates the existing revision instead of
creating a duplicate:
git commit --amend -m "$(git log -1 --format=%s)
Differential Revision: https://phabricator.services.mozilla.com/D<id>"
moz-phab uplift --train <train> --no-wip --no-rebase --yes \
upstream/<target-branch> HEAD
moz-phab abandon D<duplicate-id> --yes
The flip itself does not retroactively trigger BMO's
flag-creation block (BMO looks up the changer in the
reviewer list, finds the patch author isn't a reviewer, and
returns early without setting the flag). So after a flip you
still need step 8's manual flag-set fallback.
Reusing one worktree for several channels. Fine — just create a
fresh bug-<bug_id>-<channel> branch off each target tip. Cherry-pick
from the first channel's branch. Between channels, the stash and any
untracked files ride along.
Sec-* bug visibility. moz-phab uplift inherits the bug's
Phabricator security group — revisions created from a
media-core-security (or similar) bug are "secure" and visible only to
that group, matching the existing Phabricator attachments. Verify
this on the first revision you create before proceeding to the rest.
5b — Raw patch + BMO approval flags (fallback)
Use when moz-phab uplift isn't applicable — e.g. the bug predates
moz-phab uplift support, or the patch only exists as a text file and
the user doesn't want to turn it into a Phabricator revision. Upload
via the helper script; it can set approval flags and post the Step 7
comment in the same API call.
git format-patch -1 HEAD -o /tmp
python3 .claude/skills/uplift-request/bmo-uplift-request \
<bug_id> --attach /tmp/0001-*.patch --dry-run
The summary defaults to the patch Subject (with [PATCH n/m]
stripped); pass --summary to override. When re-submitting a
sanitized version after Step 4 flagged the existing attachment
(scenario D), pass --obsolete <old_attachment_id> (repeatable) so
the stale patch is marked obsolete atomically with the upload. Combine
--attach with --beta / --release / --esr NN (and an optional
positional comment file) to upload the patch, post the uplift form,
and set approval flags in a single API call.
After submission, re-list attachments to record the new IDs for
Step 8.
Step 6 — Draft the uplift questionnaire
The form, per
https://wiki.mozilla.org/Release_Management/Uplift_rules#Guidelines_on_approval_comments_for_Beta_and_Release,
has nine fields (same set for Beta, Release, ESR):
- User impact if declined — user-facing consequence, not repro steps.
- For sec-* bugs: state the security impact explicitly. Lead with
sec-<rating> <class> (e.g. "sec-high heap memory disclosure",
"sec-moderate UAF") and describe the concrete observable consequence
(what web content or an attacker can see/do). Do not sanitize this
field down to generic "returns incorrect data" — approvers are release
drivers who need to understand the severity they're signing off on, and
sec-approval has already gated this content.
- Is this code covered by automated tests? — Yes / No / Unknown. Answer
based on what is currently landed on the target branch, not on what the
uplift bundle will add once approved. If the test is attached/queued but
not yet in-tree on that branch, answer No and note "New test attached;
will land with the uplift." If the test is landed on trunk but the uplift
crosses into a release branch where it isn't yet backported, the answer for
that branch is still No. Only answer Yes when coverage already
exists on the target branch at the time of the approval request.
- Has the fix been verified in Nightly? — Yes / No (ask the user).
- Needs manual test from QE? — Yes / No; if Yes, provide/reference repro.
- List of other uplifts needed — dependent patches not on the target
branch.
- Risk to taking this patch — Low / Medium / High.
- Why is the change risky/not risky? — concrete justification tied to
diff size, scope, test coverage, behaviour changes.
- String changes made/needed — "none" or describe. String changes need
l10n driver approval.
- Is Android affected? — Yes / No / Unknown based on whether touched code
is shared with GeckoView.
Use the bug, the diff, and the status-firefoxNN flags to fill every field.
Keep answers tight and factual — one sentence where possible.
For sec-* bugs (already sanitized by Step 4): keep the same caution in
the text of the risk/why-risky and test-coverage fields — no function
names, no line numbers, no code snippets in those. The User impact if
declined field is the explicit exception: it must name the sec rating and
concrete security consequence so approvers can judge severity. Keep it
factual and short, but do not under-sell it.
Group uplift blocks by patch identity, not by channel. Produce one
block per distinct patch variant, listing every channel that shares it:
- Same patch applies cleanly to Beta, Release, and ESR 140, but ESR 115 needs
a rebase → 2 blocks: one headed
### Uplift Request — Firefox Beta 150 / Release 149 / ESR 140, another
headed ### Uplift Request — Firefox ESR 115.
- Same patch applies cleanly to every requested channel → 1 block headed
with all the channels it covers.
- Every channel needs a different patch → one block per channel.
Default to "one block covering all requested channels" when the patch is
small/structural and likely to cherry-pick cleanly. If backport conflicts
surface later, split the block then. Rationale: each block maps to one
attachment submission + approval-flag batch on Bugzilla — one block per
patch is the natural grouping, and duplicating identical answer text across
per-channel blocks is noise.
Step 7 — Write the markdown file
Write to the repository root as uplift-request-bug-<bug_id>.md (or
uplift-request.md if no bug ID). Use compact markdown — no blank lines
between bullets, one answer per line:
### Uplift Request — Firefox <channels this patch covers>
* **User impact if declined**: <answer>
* **Is this code covered by automated tests?**: <Yes/No/Unknown>
* **Has the fix been verified in Nightly?**: <Yes/No>
* **Needs manual test from QE?**: <Yes/No — steps or reference>
* **List of other uplifts needed**: <answer or "None">
* **Risk to taking this patch**: <Low/Medium/High>
* **Why is the change risky/not risky?**: <answer>
* **String changes made/needed**: <none or description>
* **Is Android affected?**: <Yes/No/Unknown>
*Drafted with the assistance of Claude Code — reviewed and approved by the patch author.*
The heading lists every channel the block's patch applies to — e.g.
### Uplift Request — Firefox Beta 150 / Release 149 / ESR 140 / ESR 115
for a clean-everywhere patch, or a single-channel heading for a
rebased variant. When the request covers multiple distinct patches,
concatenate one block per patch separated by a single blank line. Use the
Write tool, then tell the user the file path.
Once the answer file exists, remind the user what to do with it:
- If path 5a (moz-phab uplift) is in use — or will be in use — tell
the user to paste the relevant block from this file into the lando
uplift form at the URL
moz-phab uplift prints
(https://lando.moz.tools/uplift/request/?revisions=<rev-id>) for
each revision. Mention it explicitly, per channel — this is the
step that replaces a Bugzilla comment in the moz-phab flow and it
is easy to forget.
- If path 5b (raw-patch + BMO flags) is in use, Step 8 posts the
file contents as a Bugzilla comment automatically; no manual
paste needed.
Step 8 — Post to Bugzilla (only for path 5b; skip for path 5a)
Ask the user whether to post. Always dry-run first.
-
Check API key — never read or print it:
python3 .claude/skills/uplift-request/bmo-uplift-request --check-auth
On failure, offer the user the two options already documented in
sec-approval (persistent in ~/.config/bugzilla/config.toml, or
one-time $BMO_API_KEY) and stop. The same config is used for both
skills, so if sec-approval already works, this will too.
-
Resolve attachment(s): uplift flags go on Phabricator attachments (one
flag per target branch, often one attachment per backport patch). Use the
--list output and the local commits' D<N> trailers to pick defaults.
Ask the user to confirm. If none match (e.g. raw-patch-only), ask for the
attachment ID.
-
Dry-run per block. Each block from Step 6 corresponds to one
attachment and the channels that block covers — pass every channel flag
for that block in a single invocation:
python3 .claude/skills/uplift-request/bmo-uplift-request \
<bug_id> uplift-request-bug-<bug_id>.md \
--attachment <id> --beta --release --esr 140 --esr 115 --dry-run
Flags supported: --beta, --release, --esr NN (combine all the
channels that share the block's patch). Show the dry-run output and
confirm.
-
Post — re-run without --dry-run. When the request has multiple
blocks (distinct patch variants on different attachments), invoke the
script once per block with that block's attachment and channel flags.
-
Report the Bugzilla URL printed by the script.
Tips
- Uplift flags:
approval-mozilla-beta?approval-mozilla-release?approval-mozilla-esr{NN}? (version-specific, e.g. approval-mozilla-esr140?)
- Beta cut-offs, ESR dot-releases, and merge-day dates come from
https://whattrainisitnow.com/calendar/ — don't guess.
- String changes need l10n driver approval separate from release drivers.
- ESR uplift is additional to sec-approval when both apply.
- If
bmo-to-md isn't installed, point the user to cargo install bmo-to-md
(https://github.com/padenot/bmo-to-md).
