github.com/mozilla-firefox/firefox (link)

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Build

NSS uses GYP + Ninja as its primary build system, driven by `build.sh` (or the `mach` wrapper):

```sh
./build.sh          # debug build → ../dist/Debug/
./build.sh -o       # optimized build → ../dist/Release/
./build.sh -c       # clean + build
./mach build        # equivalent wrapper
```

Common flags:
- `--asan` / `--msan` / `--ubsan` — sanitizer builds
- `--fuzz` / `--fuz

@AGENTS.md

@AGENTS.md

@AGENTS.md

@AGENTS.md

@AGENTS.md

name: Claude Code Review

on:
  # zizmor: ignore[dangerous-triggers]
  # pull_request_target is required to access secrets for fork PRs.
  pull_request_target:
    branches: ["main"]
    types: [opened, synchronize, ready_for_review, reopened]

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  claude-review:
    permissions:
      contents: read
      pull-requests: write # post review comments
      issues

# Gemini Project Context: libyuv Row Functions

This file provides context for the core row-processing architecture of
libyuv. Use these guidelines when refactoring, reviewing, or generating
code within the `row_*.cc` files.

## Architectural Overview

Libyuv uses a dispatch system where high-level conversion functions call
optimized "Row" functions. These functions are categorized by SIMD architecture
and compiler compatibility.

## Source File Map

### x86 Architectures (32-bit and 64-bit)

*   **row_gcc.

# General workflow

@agents/prompts/common.md @agents/README.md

**Important:** `depot_tools` must be in your `PATH` for working in this checkout
(e.g., for `git new-branch` to work).

# Searching Downstream

When auditing symbol usage or finding references in downstream projects, always
prefer high-precision CodeSearch filters over raw text searches:

-   **Semantic References:** Use `usage:webrtc::SymbolName` to find actual
    call-sites.
-   **Virtual Overrides:** Use `func:MethodName` to find overrides

# Newtab Development

## Documentation
- Newtab source docs: https://firefox-source-docs.mozilla.org/browser/extensions/newtab/docs/index.html
- Design system tokens: https://firefoxux.github.io/firefox-desktop-components/ (visual reference), or locally: `toolkit/themes/shared/design-system/dist/tokens-shared.css`

## File Locations
Most of the code should be located in `browser/extensions/newtab`
- React components: `browser/extensions/newtab/content-src/components/`
- Styles (SCSS): `browser/extensions/ne

# Global instructions
Limit the amount of comments you put in the code to a strict minimum. You should almost never add comments, except sometimes on non-trivial code, function definitions if the arguments aren't self-explanatory, and class definitions and their members.

Do not remove existing comments unless they are directly related to what you are changing.

If you see a good first bug that isn't directly related to your work, don't hesitate to propose it as a good first bug (see the `file-good-first-bu

# AGENTS.md

This directory is **SpiderMonkey**, the JavaScript engine inside the
Firefox/Gecko monorepo in the parent directly. Project-wide instructions live
in `../AGENTS.md` (referenced from `../CLAUDE.md`). Notes below cover what is
specific to `js/`.

## Test workflow

Tests are run from the `js` test shell, not the browser. There are three suites:
 - **jit-test** (`src/jit-test/`) — JIT, GC, and engine internals, run with
     `mach jit-test`.
 - **jsapi-tests** (`src/jsapi-tests/`) — C++ tests o

# WebRender module instructions

WebRender is the GPU-based 2D rendering engine used by Firefox, written in Rust.
It is a standalone Cargo workspace vendored into the Firefox repository.

## Layout
- `webrender/` — the renderer crate (scene building, frame building, batching,
  clip/spatial trees, GPU backend).
- `webrender_api/` — the serializable display-list API shared with Gecko.
- `wrench/` — standalone test/replay harness (reftests, captures, YAML/RON).
- `swgl/` — software GL backend.
- `wr_g

# Layout module instructions

Scoped guidance for `layout/`. The global `../AGENTS.md` still applies.

## Start here
Read the docs in `layout/docs/` before non-trivial work.
- `layout/docs/LayoutOverview.md` for frame tree, frame construction, reflow,
  and fragmentation.

## Review
- Read `layout/docs/LayoutCodeReviewerChecklist.md` as guidance when reviewing
  layout changes.

## Testing
- When adding reftests / crashtests for standardized CSS properties, prefer
  putting them in the relevant subdirectory

{
  "mcpServers": {
    "moz": {
      "type": "http",
      "url": "https://mcp-dev.moz.tools/mcp"
    },
    "firefox-devtools": {
      "type": "stdio",
      "command": "${MACH_PYTHON:-python3}",
      "args": [
        "mach",
        "--quiet",
        "firefox-devtools-mcp",
        "--pref",
        "remote.prefs.recommended=false",
        "--pref",
        "browser.smartwindow.enabled=true",
        "--enable-privileged-context",
        "--enable-script"
      ]
    }
  }
}

{
  "mcpServers": {
    "moz": {
      "type": "http",
      "url": "https://mcp-dev.moz.tools/mcp"
    }
  }
}

---
name: gtest-parallel
description: Run Google Test binaries in parallel using the gtest-parallel script. Use when needing to speed up test execution, run flaky tests with repeat, or filter specific tests.
---

# gtest-parallel

`gtest-parallel` is a script that executes Google Test binaries in parallel,
providing speedup for single-threaded tests and tests that do not run at 100%
CPU.

## Location

The script is located at `third_party/gtest-parallel/gtest-parallel`.

## Core Flags

### Filtering Tests

---
name: include-cleaner
description: Runs the WebRTC include-cleaner tool (IWYU replacement) to fix headers in C++ files. Use when preparing a CL for upload, after modifying .cc or .h files, or when instructed to fix include regressions.
---

# WebRTC Include Cleaner

This skill provides instructions for using
`tools_webrtc/iwyu/apply-include-cleaner`, a tool that automatically manages C++
`#include` directives in the WebRTC codebase. It ensures that every header used
is explicitly included and that unuse

---
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 th

---
name: stack-split-jj
description: Steps to reliably split a commit/change using the jj (jujutsu) VCS
allowed-tools:
  - Bash(jj log:*),
  - Bash(jj show:*),
  - Bash(jj split:*),
  - Bash(jj commit:*),
  - Bash(jj new:*),
  - Bash(jj describe:*),
  - Bash(jj rebase:*),
  - Bash(jj edit:*),
  - Bash(jj restore:*),
  - Bash(jj file show:*),
  - Read,
  - Grep,
  - Glob
---

# If the commit is to be split based on path

1. Identify the commit to split - Use jj log to find the revision ID of the commit you 

---
name: file-good-first-bug
description: Use this skill when the user wants to file good-first-bugs in Bugzilla for Firefox. A good-first-bug is a narrow, self-contained, low-risk task scoped so a first-time contributor can land it without deep context. Sources include lint warnings, small typos, dead-code removal, mechanical refactors, docs conversions, or any other small task the user points at. Opens a prefilled `enter_bug.cgi` form per bug in the user's browser for them to submit. Trigger on phrases l

---
name: android-new-module
description: Guide for creating new Android gradle modules in the android-components project.
---

## Overview

This skill helps you create new Android gradle modules following Mozilla's conventions and structure. Components are organized into categories: `browser`, `concept`, `feature`, `lib`, `service`, `support`, `ui`, and `compose`.

## Component Categories

- **browser** - High-level browser components (engine, menu, state, etc.)
- **compose** - Jetpack Compose components
-

---
name: gecko-web-standard-implementation
description: You MUST use this skill when working with C++, C, Rust code to implement or modify WebIDL interfaces and their native implementations.
---


## Workflow
- When implementing or reviewing new web-exposed interfaces, compare the code against the specification. The relevant link should be in the .webidl file. When reviewing, explicitly check each method's implementation against the corresponding spec algorithm and note any discrepancies. If `webspec-index

---
name: api-compat-reviewer
description: Automated code review for backward-incompatible changes in WebRTC public headers. Use this skill to catch renames/removals/signature changes in api/ (and other downstream-consumed headers like pc/session_description.h) that will break Chromium and internal builds, and to verify a deprecation polyfill is in place.
---

# API Compat Reviewer Skill

libWebRTC is consumed by downstream projects (Chromium, and internal,
closed-source Google code) that build out-of-tree 

---
name: file-good-first-bug
description: Use this skill when the user wants to file good-first-bugs in Bugzilla for Firefox. A good-first-bug is a narrow, self-contained, low-risk task scoped so a first-time contributor can land it without deep context. Sources include lint warnings, small typos, dead-code removal, mechanical refactors, docs conversions, or any other small task the user points at. Opens a prefilled `enter_bug.cgi` form per bug in the user's browser for them to submit. Trigger on phrases l

---
name: js-perf-investigation
description: >
  Structured performance opportunity investigation for SpiderMonkey (the Firefox JavaScript engine).
  Use this skill when the user wants to investigate JS engine performance, profile SpiderMonkey,
  find optimization opportunities, write performance patches, or evaluate benchmark regressions.
  Trigger on mentions of: profiling JS, SpiderMonkey performance, JIT optimization, benchmark
  regression analysis, shell benchmarking, or any request to make JS workloa

---
name: stmo
description: >
  Manage Redash queries and dashboards on Mozilla's STMO (sql.telemetry.mozilla.org)
  using stmo-cli. Use when the user wants to explore telemetry data on STMO, write,
  deploy, or execute Redash queries, manage dashboards, or discover data sources.
  Also trigger on mentions of STMO, Redash, sql.telemetry.mozilla.org, or when the
  user wants to query Mozilla telemetry data (as opposed to probe/metric discovery,
  which is mozdata territory).
allowed-tools:
  - Bash(stmo-cli:

---
name: nimbus-prefs
description: >
  Use this skill when a Firefox preference has to be remotely controllable: putting a new feature
  behind a pref so it can be experimented on, rolled out gradually, or disabled remotely via
  Nimbus. Covers declaring prefs (StaticPrefList.yaml, firefox.js), adding a feature to
  toolkit/components/nimbus/FeatureManifest.yaml, choosing between `fallbackPref` and `setPref`,
  reading values from JS and C++, recording exposure events, and pairing the pref with Glean
  tel

---
name: stack-split-jj
description: Steps to reliably split a commit/change using the jj (jujutsu) VCS
allowed-tools:
  - Bash(jj log:*),
  - Bash(jj show:*),
  - Bash(jj split:*),
  - Bash(jj commit:*),
  - Bash(jj new:*),
  - Bash(jj describe:*),
  - Bash(jj rebase:*),
  - Bash(jj edit:*),
  - Bash(jj restore:*),
  - Bash(jj file show:*),
  - Read,
  - Grep,
  - Glob
---

# If the commit is to be split based on path

1. Identify the commit to split - Use jj log to find the revision ID of the commit you 

---
name: git-cl
description: Provides commands for interacting with Gerrit CLs using git cl, including issue management and non-interactive uploads.
---

# git cl Skill

This skill provides instructions and best practices for using `git cl` in WebRTC
development.

## Available Workflows

- **Uploading Changes**: For non-interactive uploads, handling chained branches,
  and presubmit warnings, see [references/upload.md](references/upload.md).

## Future Extensions

This skill can be extended to cover:

- `g

---
name: firefox-desktop-frontend
description: You MUST use this skill when working with HTML, JS, CSS and other front-end code.
---


## Workflow
- Whenever you're building, if `./mach build` was previously run and you have not made any changes to C++ or Rust code (nor rebased past incoming changes to such code), you can use `./mach build faster` to skip the compilation and linking steps and only build the front-end code. This can save a lot of time when you're only working on the browser/ or toolkit/ cod

---
name: android
description: Workflow guide when working with Android builds or the mobile/ directory.
---

## Workflow
- Instead of `gradlew`, use `./mach gradle` as the wrapper. Use `-p` argument of gradle if you need to run in a subdirectory

---
name: bug-filing
description: File a Bugzilla bug for Firefox/Gecko work, or draft a bug summary and description. Use when the user asks to file a bug, wants a bug summary/description for a change, or needs to report a defect/enhancement/task. Determines the product and component with `mach file-info`, drafts the summary and description, and opens a prefilled enter_bug.cgi form in the browser for the user to submit.
allowed-tools:
  - Bash(./mach file-info:*)
  - Bash(python3 .agents/skills/bug-filing/f

---
name: media-patch-review
description: >
  Reviews dom/media code changes ONLY — not any other component. Fans out the
  in-tree dom/media review checklists (dom/media/docs/review/*.md) against a patch,
  one opus reviewer per checklist, then collects the findings. Temporary local tool
  until bugbug's /patch_review loads these docs directly. Triggers on:
  "media-patch-review", "/media-patch-review".
argument-hint: <"diff", "local", or D-number>
allowed-tools: [Agent]
---

# media-patch-review — qui

---
name: webspec-index
description: Use webspec-index to query WHATWG, W3C, IETF and TC39 web specifications from the command line
---

# webspec-index

Query WHATWG, W3C, IETF and TC39 web specifications from the command line.

Use `webspec-index` whenever you need to understand what a web spec says — algorithm steps, section content, cross-references, or whether a spec anchor exists. Specs are fetched and cached locally on first use.

## Available specs

Assume that all specs from WHATWG, W3C, IETF and

---
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 th

---
name: stack-reorganize-jj
description: Analyze a range of local commits, and reorganize them to minimize latency and friction in the review and landing process. To achieve this, commits can be split, reordered, squashed / grouped, or even rewritten. In the final commit series / "patch stack", the codebase should build, lint, and test cleanly after every commit, and each individual commit should stand on its own.
when_to_use: Before a patch (or a patch series) is submitted for first review, if the user a

---
name: stmo
description: >
  Manage Redash queries and dashboards on Mozilla's STMO (sql.telemetry.mozilla.org)
  using stmo-cli. Use when the user wants to explore telemetry data on STMO, write,
  deploy, or execute Redash queries, manage dashboards, or discover data sources.
  Also trigger on mentions of STMO, Redash, sql.telemetry.mozilla.org, or when the
  user wants to query Mozilla telemetry data (as opposed to probe/metric discovery,
  which is mozdata territory).
allowed-tools:
  - Bash(stmo-cli:

---
name: webrtc-changelog
description: Generate a professional HTML changelog from WebRTC git logs. Automatically categorizes changes, includes a high-level summary, and provides detailed commit and review links.
---

# WebRTC Changelog Generator

`webrtc-changelog` automates the generation of a professional, categorized HTML
report for WebRTC changes.

## Workflow

1. **Fetch Branch Information:** Navigate to
   `https://chromiumdash.appspot.com/branches` and extract the current and
   previous branch num

---
name: mozlint
description: You MUST use this skill when working with Firefox's linting infrastructure (mozlint), adding new linters, modifying existing linters, running linters, or dealing with linting issues.
---


## Overview
Firefox's linting infrastructure (mozlint) provides a unified way to run various linters across the codebase. It integrates multiple linters including ESLint, Stylelint, ruff, clippy, clang-format, and many others.

## Workflow
- Run `./mach lint` without arguments to lint all mo

---
name: firefox-desktop-frontend
description: You MUST use this skill when working with HTML, JS, CSS and other front-end code.
---


## Workflow
- Whenever you're building, if `./mach build` was previously run and you have not made any changes to C++ or Rust code (nor rebased past incoming changes to such code), you can use `./mach build faster` to skip the compilation and linking steps and only build the front-end code. This can save a lot of time when you're only working on the browser/ or toolkit/ cod

---
name: nimbus-prefs
description: >
  Use this skill when a Firefox preference has to be remotely controllable: putting a new feature
  behind a pref so it can be experimented on, rolled out gradually, or disabled remotely via
  Nimbus. Covers declaring prefs (StaticPrefList.yaml, firefox.js), adding a feature to
  toolkit/components/nimbus/FeatureManifest.yaml, choosing between `fallbackPref` and `setPref`,
  reading values from JS and C++, recording exposure events, and pairing the pref with Glean
  tel

---
name: webspec-index
description: Use webspec-index to query WHATWG, W3C, IETF and TC39 web specifications from the command line
---

# webspec-index

Query WHATWG, W3C, IETF and TC39 web specifications from the command line.

Use `webspec-index` whenever you need to understand what a web spec says — algorithm steps, section content, cross-references, or whether a spec anchor exists. Specs are fetched and cached locally on first use.

## Available specs

Assume that all specs from WHATWG, W3C, IETF and

---
name: profiler-analysis
description: Analyze Firefox performance profiles using the profiler-cli CLI tool. Trigger when given a profiler.firefox.com or share.firefox.dev link, a local profile path, or when the user wants to investigate an issue in a Firefox profile. Always use this skill instead of WebFetch for Firefox profiler URLs; WebFetch only retrieves the profiler UI's HTML shell and cannot access profile data, whereas profiler-cli downloads and parses the actual profile into a local daemon that s

---
name: mozlint
description: You MUST use this skill when working with Firefox's linting infrastructure (mozlint), adding new linters, modifying existing linters, running linters, or dealing with linting issues.
---


## Overview
Firefox's linting infrastructure (mozlint) provides a unified way to run various linters across the codebase. It integrates multiple linters including ESLint, Stylelint, ruff, clippy, clang-format, and many others.

## Workflow
- Run `./mach lint` without arguments to lint all mo

---
name: js-perf-investigation
description: >
  Structured performance opportunity investigation for SpiderMonkey (the Firefox JavaScript engine).
  Use this skill when the user wants to investigate JS engine performance, profile SpiderMonkey,
  find optimization opportunities, write performance patches, or evaluate benchmark regressions.
  Trigger on mentions of: profiling JS, SpiderMonkey performance, JIT optimization, benchmark
  regression analysis, shell benchmarking, or any request to make JS workloa

---
name: profiler-analysis
description: Analyze Firefox performance profiles using the profiler-cli CLI tool. Trigger when given a profiler.firefox.com or share.firefox.dev link, a local profile path, or when the user wants to investigate an issue in a Firefox profile. Always use this skill instead of WebFetch for Firefox profiler URLs; WebFetch only retrieves the profiler UI's HTML shell and cannot access profile data, whereas profiler-cli downloads and parses the actual profile into a local daemon that s

---
name: gn-check-autofix
description: Automatically fix GN check errors in WebRTC BUILD.gn files. Use when encountering "Include not allowed", "rtc_source_set shall not contain cc files", or when needing to clean up non-absolute dependencies.
---

# GN Check Autofix

This skill provides instructions for using `tools_webrtc/gn_check_autofix.py` to
automatically resolve common GN build configuration errors in WebRTC.

## Core Workflows

### Fix Missing Dependencies

When you see "Include not allowed" errors

---
name: documentation
description: Use this skill when working with Firefox documentation,
  including building documentation with `./mach doc`,
  fixing Sphinx build errors or warnings, modifying existing
  documentation, or adding new docs.
---

## Overview

Firefox documentation is built using **Sphinx**
through the `./mach doc` command. Documentation sources are distributed
throughout the repository and are written in **Markdown (`.md`)**.

The documentation system integrates:

-   Sphinx
-   MyST par

---
name: android-new-module
description: Guide for creating new Android gradle modules in the android-components project.
---

## Overview

This skill helps you create new Android gradle modules following Mozilla's conventions and structure. Components are organized into categories: `browser`, `concept`, `feature`, `lib`, `service`, `support`, `ui`, and `compose`.

## Component Categories

- **browser** - High-level browser components (engine, menu, state, etc.)
- **compose** - Jetpack Compose components
-

---
name: documentation
description: Use this skill when working with Firefox documentation,
  including building documentation with `./mach doc`,
  fixing Sphinx build errors or warnings, modifying existing
  documentation, or adding new docs.
---

## Overview

Firefox documentation is built using **Sphinx**
through the `./mach doc` command. Documentation sources are distributed
throughout the repository and are written in **Markdown (`.md`)**.

The documentation system integrates:

-   Sphinx
-   MyST par

---
name: perf-regression-triage
description: >
  Handle a Perfherder performance regression bug end to end: read the alert bug, confirm
  whether the regression is real, find the cause, and iterate to a fix. Use when the user
  has a Perfherder/browsertime regression bug (the "N% <test> ... regression on <date>"
  bugs filed in Testing::Performance), needs to establish whether an alert summary is a
  real regression, is interpreting a PerfCompare baseRev/newRev comparison, or asks what
  to do about a patc

---
name: pre-reviewer
description: Automated pre-review tool to inspect C++ style, concurrency safety, test quality, and CL descriptions before submitting code for human review.
---

<!-- go/cmark -->

<!--* freshness: {owner: 'tommi' reviewed: '2026-06-12'} *-->

# Pre-Reviewer Skill

This skill acts as a pre-review confidence check tool for WebRTC C++
contributions. Use this skill to evaluate code changes for common C++
anti-patterns, concurrency bugs, test hygiene issues, and CL description
completeness

---
name: android
description: Workflow guide when working with Android builds or the mobile/ directory.
---

## Workflow
- Instead of `gradlew`, use `./mach gradle` as the wrapper. Use `-p` argument of gradle if you need to run in a subdirectory

---
name: hta-reviewer
description: Automated code review following Harald Alvestrand's (hta@) standards for WebRTC. Use this skill to analyze CLs for thread safety, process hygiene, architectural robustness, and modern C++ adoption.
---

# HTA Reviewer Skill

This skill adopts the "Reviewer's Lens" of Harald Alvestrand, a senior WebRTC
engineer. It provides direct, technical, and process-oriented feedback on code
changes.

## Core Mandates

### 1. Process Hygiene

- **Freshness**: Ensure the CL is rebased 

---
name: gecko-web-standard-implementation
description: You MUST use this skill when working with C++, C, Rust code to implement or modify WebIDL interfaces and their native implementations.
---


## Workflow
- When implementing or reviewing new web-exposed interfaces, compare the code against the specification. The relevant link should be in the .webidl file. When reviewing, explicitly check each method's implementation against the corresponding spec algorithm and note any discrepancies. If `webspec-index

---
name: perftest
description: >
  Run Firefox performance tests locally or in CI. Use when the user asks how to run a
  perf test, needs the mach invocation for Raptor, Talos, MozPerftest, AWSY, or
  browsertime, wants to push perf tests to try, wants to run the tests belonging to an
  alert summary (`mach try perf --alert <id>`), or mentions `mach try perf`,
  `mach perftest`, `mach raptor`, or `mach talos-test`. Covers picking the right
  harness, finding a test's name, and the local-vs-CI tradeoff.
  N

---
name: specmap
description: Map relationships between a web spec section, its Firefox implementation code, and Web Platform Tests. Use when starting work on a spec feature, checking implementation coverage, or finding which WPTs to enable.
argument-hint: "[spec-url-or-fragment] [optional: specific-algorithm]"
allowed-tools:
  - Bash(searchfox-cli:*)
  - Bash(webspec-index:*)
  - Bash(curl:*)
  - Bash(jq:*)
  - Read
  - Grep
  - Glob
---

# SpecMap: Spec-Code-WPT Mapping

**Spec URL or fragment**: $0
**Sp

---
name: accessibility-frontend-review
description: >
  Performs an accessibility code review of a local diff or Phabricator revision in the style of the
  Firefox accessibility team. Use this skill whenever the user asks to review a Phabricator
  patch or revision for accessibility issues, mentions a D-number (like D284142) in the
  context of accessibility review, asks "does this patch have any a11y issues", or wants
  to check a diff against accessibility guidelines. Also use it when the user says thing

---
name: specmap
description: Map relationships between a web spec section, its Firefox implementation code, and Web Platform Tests. Use when starting work on a spec feature, checking implementation coverage, or finding which WPTs to enable.
argument-hint: "[spec-url-or-fragment] [optional: specific-algorithm]"
allowed-tools:
  - Bash(searchfox-cli:*)
  - Bash(webspec-index:*)
  - Bash(curl:*)
  - Bash(jq:*)
  - Read
  - Grep
  - Glob
---

# SpecMap: Spec-Code-WPT Mapping

**Spec URL or fragment**: $0
**Sp

---
name: perf-regression-triage
description: >
  Handle a Perfherder performance regression bug end to end: read the alert bug, confirm
  whether the regression is real, find the cause, and iterate to a fix. Use when the user
  has a Perfherder/browsertime regression bug (the "N% <test> ... regression on <date>"
  bugs filed in Testing::Performance), needs to establish whether an alert summary is a
  real regression, is interpreting a PerfCompare baseRev/newRev comparison, or asks what
  to do about a patc

---
name: media-patch-review
description: >
  Reviews dom/media code changes ONLY — not any other component. Fans out the
  in-tree dom/media review checklists (dom/media/docs/review/*.md) against a patch,
  one opus reviewer per checklist, then collects the findings. Temporary local tool
  until bugbug's /patch_review loads these docs directly. Triggers on:
  "media-patch-review", "/media-patch-review".
argument-hint: <"diff", "local", or D-number>
allowed-tools: [Agent]
---

# media-patch-review — qui

---
name: accessibility-frontend-review
description: >
  Performs an accessibility code review of a local diff or Phabricator revision in the style of the
  Firefox accessibility team. Use this skill whenever the user asks to review a Phabricator
  patch or revision for accessibility issues, mentions a D-number (like D284142) in the
  context of accessibility review, asks "does this patch have any a11y issues", or wants
  to check a diff against accessibility guidelines. Also use it when the user says thing

---
name: stack-reorganize-jj
description: Analyze a range of local commits, and reorganize them to minimize latency and friction in the review and landing process. To achieve this, commits can be split, reordered, squashed / grouped, or even rewritten. In the final commit series / "patch stack", the codebase should build, lint, and test cleanly after every commit, and each individual commit should stand on its own.
when_to_use: Before a patch (or a patch series) is submitted for first review, if the user a

---
name: spec-trace
description: Trace a claim about web spec behaviour through the algorithm call chain and produce a Bugzilla-ready markdown trace ending in a REACHED / NOT REACHED / INCONCLUSIVE verdict. Use when a bug says "the spec says X should happen" and you need to check whether it does, when asked where in the spec some event gets fired or some state gets set, or when a reporter's expected-results section needs a spec citation it did not provide.
argument-hint: "[--gecko] <question in prose>"
all

---
name: fluent-migration
description: >
  Use this skill when a patch or local changes rename, restructure, move, or
  replace Fluent (.ftl) strings - or migrate legacy .properties strings to Fluent
  - and you need a migration recipe in python/l10n/fluent_migrations so existing
  translations carry over. You read the diff, classify each changed string, write
  the recipe by hand, and validate it with the in-tree `./mach
  fluent-migration-test`. Triggers: "write/generate a fluent migration", "migrate
  t

---
name: perftest
description: >
  Run Firefox performance tests locally or in CI. Use when the user asks how to run a
  perf test, needs the mach invocation for Raptor, Talos, MozPerftest, AWSY, or
  browsertime, wants to push perf tests to try, wants to run the tests belonging to an
  alert summary (`mach try perf --alert <id>`), or mentions `mach try perf`,
  `mach perftest`, `mach raptor`, or `mach talos-test`. Covers picking the right
  harness, finding a test's name, and the local-vs-CI tradeoff.
  N

---
name: spec-trace
description: Trace a claim about web spec behaviour through the algorithm call chain and produce a Bugzilla-ready markdown trace ending in a REACHED / NOT REACHED / INCONCLUSIVE verdict. Use when a bug says "the spec says X should happen" and you need to check whether it does, when asked where in the spec some event gets fired or some state gets set, or when a reporter's expected-results section needs a spec citation it did not provide.
argument-hint: "[--gecko] <question in prose>"
all

---
name: fluent-migration
description: >
  Use this skill when a patch or local changes rename, restructure, move, or
  replace Fluent (.ftl) strings - or migrate legacy .properties strings to Fluent
  - and you need a migration recipe in python/l10n/fluent_migrations so existing
  translations carry over. You read the diff, classify each changed string, write
  the recipe by hand, and validate it with the in-tree `./mach
  fluent-migration-test`. Triggers: "write/generate a fluent migration", "migrate
  t

---
name: bug-filing
description: File a Bugzilla bug for Firefox/Gecko work, or draft a bug summary and description. Use when the user asks to file a bug, wants a bug summary/description for a change, or needs to report a defect/enhancement/task. Determines the product and component with `mach file-info`, drafts the summary and description, and opens a prefilled enter_bug.cgi form in the browser for the user to submit.
allowed-tools:
  - Bash(./mach file-info:*)
  - Bash(python3 .agents/skills/bug-filing/f