// Firefox bug triage assistant for media, web conferencing, and graphics related issues.
Help prepare a Firefox security approval request by analyzing local commits/changes and drafting answers to the sec-approval questionnaire. Use when setting sec-approval? on a Bugzilla bug.
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).
Generate technical documentation for a specified technology domain with optional customization.
Generate or modify Firefox mozconfig build configuration files. Use when the user asks to create a mozconfig, configure a build, set up ASan/TSan/debug builds, or match try server configurations.
Firefox bug triage assistant for determining if a bug severity rating of S1 or S2 is warranted, and to gather information for triaging and prioritization.
Launch a local web server and open a browser page listing all bug triage reports in ./reports, with live JS text filtering.
| name | media-bug-triage |
| description | Firefox bug triage assistant for media, web conferencing, and graphics related issues. |
This skill helps triage Mozilla Bugzilla bugs related to media issues in Firefox, but can be applied to other bug types as well.
Typical use:
/media-bug-triage 123456
The skill walks through a set of phases during analysis:
Resolve both settings before doing anything else. State the active scope profile when beginning analysis.
Bug ID — Extract from user input. Accepted formats:
1234567Bug 1234567https://bugzilla.mozilla.org/show_bug.cgi?id=1234567If no bug ID is provided, prompt the user:
Welcome to Firefox Bug Triage Assistant!
Please provide a Bugzilla bug number to analyze (e.g., 1234567) and scope profile (optional, e.g. "graphics", "web-conferencing", "android"). If you don't specify a scope profile, I'll infer it from the bug's component.
Example input: `1234567 scope:graphics`
Scope profile — If the user specified a topic (e.g. "graphics", "web-conferencing", "android"), use that profile from the Scope Profiles section. If not specified, infer from the triage bug's component after fetching it:
mediaweb-conferencinggraphicsandroidmedia-and-web-conferencing or ask the user.Tips For Agents - Input may include short suggestions Agents can act on. For example: /media-bug-triage 2023481 media [agent tip: triage 2023379 as a part of your analysis.]
Verbosity — Be explicit about which workflow step you are in or transitioning to as you execute this skill.
Use Mozilla's Bugzilla REST API directly through WebFetch. Do not use the moz MCP server for Bugzilla access.
Parse ../shared/Bugzilla.md for details on how to access and use Bugzilla data effectively during this triage process. Check for updates, this skill is a critical part of our workflow.
Track the following for inclusion in the final report:
Limit searches to the components defined by the active scope profile. See the Scope Profiles section.
searchfox-cli --help for usage.The active scope profile defines which Bugzilla products and components are searched during the Bugzilla Investigation step. Resolved at invocation — see Run Configuration.
Apply the Run Configuration section: extract the bug ID from user input and resolve the scope profile. If no bug ID was provided, prompt the user as described in Run Configuration. State the active scope profile before proceeding.
In the ./reports directory, a previous report for this bug may already exist. If you detect one, inform the user and ask if we should continue. If the user prefers not to continue, end the skill.
Fetch the initial bug report, including:
/rest/bug/{id}/history — fetched in parallel with the above. This records all field changes (who changed what, from what value, to what value, and when). Pay particular attention to:
firefox-core-security, core-security, media-core-security)sec-bounty, needinfo)Print a brief summary of the bug including summary, reporter, reported date (bug age), severity/priority, and note if the bug is security sensitive.
Before proceeding with analysis, check if the bug is closed.
A bug is considered closed if its status is one of: RESOLVED, VERIFIED, CLOSED.
If the bug is closed, inform the user and stop:
Bug {BUG_ID} is already closed.
Status: {STATUS}
Resolution: {RESOLUTION}
Summary: {SUMMARY}
This bug was resolved as "{RESOLUTION}" and does not require triage analysis.
Would you like to analyze a different bug? Please provide another bug number, or type "exit" to end.
If the bug is open (status is NEW, UNCONFIRMED, ASSIGNED, REOPENED, etc.), proceed with analysis.
Use the skills outlined in Bugzilla.md to process information contained on the bug report.
Bugzilla emails to recognize when processing a bug report:
mozilla.com, mozilla.org, mozilla.net — Likely Mozilla employees. Their feedback carries more weight, and seeking their input is straightforward.alice0775@gmail.com — A prolific external reporter known for accuracy in reporting and testing media-related bugs. Their feedback and confirmation is likely accurate. (A simple cc on bugs is common though and carries little weight.)If the reporter mentions this issue is a regression, track the reporting timeline of when the issue was first observed and any information about what may have caused the regression. This information is often found in the initial bug report but may also appear in follow-up comments.
mozregression and are sharing results.Tracking the reporting timeline helps validate assumptions, visualize when a regression occurred, or identify the range of changes that may have caused it.
When investigating regressions, we may need to ask for:
If the bug report lacks critical information:
If the bug is associated with crash signature(s), check Socorro for crash volume data for each signature. Attempt to incorporate crash volume changes into the analysis timeline and use this information to validate assumptions or provide additional context about impact.
Auto-play (terms: auto play, autoplay, play blocking, video blocking):
As you triage, assess bugs for "good first bug" qualities and note this in your summaries. You may come across existing good first bugs tagged with the good-first-bug keyword.
Good First Bug qualities:
Based on the information gathered, evaluate these two questions:
1. Is the issue clearly understood and the resolution evident?
"Do we have enough information to confidently describe the issue and propose a clear solution?"
2. Is the issue likely non-reproducible?
"Is there insufficient, inconsistent, or contradictory information that makes reproduction unlikely without further input from the reporter?"
Based on the information gathered, make a quick assessment of the bug's severity. Use the Bugzilla severity definitions as a reference, but apply your judgment based on the specific symptoms and impact described in the bug report. Report your assessment and reasoning to the user.
Goal: Broaden our view beyond the single bug report by searching for similar reports, following bug relationships, and building a picture of the issue landscape. The output is a structured set of related bugs organized by relevance — including duplicate candidates, related meta bugs, and any patterns suggesting a common root cause. Use the information you have gathered so far to guide targeted searches and relation-following.
From the bug summary, symptoms, and component, extract 5–10 targeted search terms. Prefer:
Avoid generic terms ("crash", "broken", "doesn't work") that will produce noisy, unrelated results.
Search Bugzilla using the derived terms. Apply the component restrictions from the Tools Access section and limit results to bugs from the past 12 months unless the issue appears older.
Also seed the search with any bugs already in the triage bug's see_also, depends_on, and
blocks fields — these are highest-confidence related bugs and should be retrieved first.
For each result, fetch a lightweight summary sufficient to assess relevance:
duplicate_of or non-empty see_also fieldFor each result from Phase B, make a quick relevance judgment:
Be selective. Fetch full data only for bugs that clearly warrant it — the goal is signal, not coverage.
For high-relevance bugs, follow their see_also, duplicate_of, depends_on, and blocks
relations to discover additional related bugs.
Relation reach limit: Do not follow relations more than 3 hops from the original triage bug. This prevents runaway traversal on densely connected bug clusters.
With the gathered data, perform the following analysis:
Duplicate identification — Identify bugs that appear to describe the same issue. Note the oldest open report (typically the canonical one to keep when marking duplicates).
Clustering — If there are multiple related bugs, group them by apparent root cause or symptom. For each cluster, assess:
Dependency mapping — Note any depends_on / blocks relationships that affect
prioritization — e.g., if the triage bug blocks a high-priority issue.
Root cause signals — Across all gathered bugs, note any recurring patterns (same code path, same preferences, same platform or hardware combination) that may point toward a common root cause.
Present a summary of findings (2–3 sentences) to the user, including key related bugs.
Prompt for next steps:
2, bug identifier).If the triage bug likely reports a valid issue in Firefox and we have a good understanding of it, investigate the codebase to understand where the issue might originate.
searchfox-cli or grep toolsThis investigation helps:
At this point, you should have a good understanding of the issue, its symptoms, and possible causes. Determine if we need to ask the reporter or others for additional information to confirm our understanding. This is particularly important if there are information gaps preventing a confident assessment, or if there are multiple possible causes that need to be narrowed down. Requesting more information is often more economical than having developers analyze an issue with incomplete information.
Draft an appropriate response using either:
Response guidelines:
Prior to generating a response, check over each question your will propose and ask yourself if the information is already available in the bug report. If so, remove that question and note the answer.
Generate a detailed triage report and summary in markdown format. See the Analysis Report Format section for structure details. Also print out a proposed response to the user.
Always write the report to a ./reports sub-directory with the filename bug-{BUG_ID}-triage.md. If the file already exists, create a new file with a numeric suffix (e.g., bug-{BUG_ID}-triage-2.md).
Prompt for next steps:
When analysis is complete and a report is generated, end the skill. Before ending, update the FUNCTIONALITY.md file with any new information or insights gained that may be useful for future analyses. Also suggest any improvements to this skill that would make future analyses more effective or efficient.
(end of workflow steps)
Suggested structure for the triage report. Adjust as needed based on available information.
Safety rules:
Format Notes
# Bug {BUG_ID} Triage Analysis
**Generated:** {CURRENT_DATE}
**Bug URL:** https://bugzilla.mozilla.org/show_bug.cgi?id={BUG_ID}
## Bug Information
- **Summary:** {SUMMARY}
- **Reporter:** {REPORTER}
- **Status:** {STATUS}
- **Product:** {PRODUCT}
- **Component:** {COMPONENT}
- **Created:** {CREATION_TIME}
## Research Summary and Key Findings
Detail the issue, symptoms, and any relevant information gathered from the bug report, related bugs,
and codebase investigation. Summarize key findings. Identify other Bugzilla reports that are related
or possible duplicates. Note that codebase inspection results, if completed, are detailed separately below.
## Regression Timeline
If applicable, summarize any information about when this issue was first observed and what may have
caused the regression. This information is often found in the initial bug report or in follow-up comments.
## Assessment
- **Suggested Severity:** S1/S2/S3/S4/N/A/--
- **Suggested Priority:** P1/P2/P3/P5/--
## Assessment Reasoning
[2-3 paragraphs maximum.]
## Codebase Investigation
Detail any codebase investigation performed, including relevant files examined and specific areas
worth investigating further based on your research.
### Relevant Files Examined
- [file path]: [what it contains]
- ...
### Findings
[What you discovered from investigating the code]
### Suggested Investigation Areas
[Specific code areas developers should look at]
## Bugzilla Use Tracking
- Total Bugzilla Queries: {TOTAL_QUERIES}
- Total Bugs Processed: {TOTAL_BUGS}
- Estimated Download Bandwidth Used: {BANDWIDTH} MB
- Inaccessible Bugs Due to Permissions: {INACCESSIBLE_BUGS}
Use these templates as starting points, customizing for each bug. Full templates are in the CANNED_RESPONSES.md supplement file.
| ID | Use When | Template Summary |
|---|---|---|
need-str | STR missing/unclear | Request specific reproduction steps |
need-testcase | Need minimal test | Request reduced HTML/JS/CSS example |
need-profile | Need logs | Request Firefox profile via about:logging |
need-crash-report | Crash without report | Request bp-* IDs from about:crashes |
more-info-needed | General info gap | Request version, OS, extensions, regression info |
need-regression-range | Possible regression | Suggest mozregression bisection |
need-system-info | Need hardware/system details | Request about:support info |
| ID | Use When | Template Summary |
|---|---|---|
confirmed | Reproduced issue | Confirm with environment details |
investigating | Looking into it | Acknowledge and request patience |
| ID | Use When | Template Summary |
|---|---|---|
duplicate | Same as another bug | Link to duplicate, explain |
wontfix | Won't be fixed | Explain reasoning |
worksforme | Can't reproduce | Share test environment, request more info |
incomplete | No response to needinfo | Close with invitation to refile |
| ID | Use When | Template Summary |
|---|---|---|
fuzzing-thanks | Fuzzer-found bug | Thank for fuzzing contribution |
first-time-contributor | New reporter | Welcome message |
good-report | Quality report | Thank for clear details |
| ID | Use When | Template Summary |
|---|---|---|
security-notice | Security implications | Restrict visibility, link to bounty program |
moved-component | Wrong component | Explain the move |
needs-platform-team | Platform-specific | Add platform specialists |