// 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.
| name | s2-validation |
| description | 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. |
This skill helps analyze Mozilla Bugzilla bugs to determine if a severity rating of S1 or S2 is warranted, and to gather information for triaging and prioritization.
Typical use:
/s2-validation 123456 scope:media [tip: scan bug 654321, it may help with 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 S2 Validation 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: /s2-validation 2023481 scope:media [agent tip: scan 2023379, which is a solid S2, for comparison.]
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.
The following are examples of Bugzilla REST API endpoints that may be useful during triage. This is not an exhaustive list, but rather a reference for common queries. Always refer to the official Bugzilla REST API documentation for the most up-to-date information: https://bugzilla.readthedocs.io/en/latest/api/core/v1/bug.html
GET /rest/bug/{id}
GET /rest/bug/{id}/comment
GET /rest/bug/{id}/history
GET /rest/bug/{id}/attachment
GET /rest/bug?product=...&component=...&creation_time=...&summary=...
Use the include_fields query parameter to limit response size when only a subset of fields are needed. For example:
GET /rest/bug/{id}?include_fields=id,summary,status,product,component
In some instances, the bug in question may be security-sensitive and may not be accessible without appropriate permissions. In such cases, you may encounter permission errors when attempting to fetch bug data. If this occurs, prompt the user to provide an API key with the necessary permissions to access security-sensitive bugs. If the user provides an API key, use it for all subsequent Bugzilla API requests in the current session. If the user chooses not to provide an API key, note that security-sensitive information will be inaccessible for this analysis.
If an API key is provided, ensure that it is used securely and only for the duration of the current session. Do not cache or store the API key beyond this session.
If, in your opinionn, a security report warrants a bounty payout and has not already been tagged as such, please make the recommendation to enable that in the report.
However, bounty reccomendations should only be made when there is an external reporter who has provided sufficient information to make a strong case for the severity and impact of the issue. Any reporter with a Mozilla email address or an internal affiliation should not be considered an external reporter for the purposes of bounty reccomendations, as they may have access to internal information and resources that external reporters do not.
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.
Bug reports may or may not be classified. For more detailed information see https://firefox-source-docs.mozilla.org/bug-mgmt/guides/severity.html
| Severity | Meaning |
|---|---|
| S1 | Catastrophic: Blocks development/testing, affects 25%+ users, data loss, no workaround, will cause users to switch products |
| S2 | Serious: Major functionality impaired, high impact, no satisfactory workaround, may cause users to switch products |
| S3 | Normal: Blocks non-critical functionality, workarounds in Firefox exist |
| S4 | Small/Trivial: Minor significance, cosmetic, low user impact |
| N/A | Not Applicable: Task or Enhancement type bugs |
| -- | Unknown: Not enough information to assess |
| Priority | Meaning |
|---|---|
| P1 | Fix in current release cycle (critical) |
| P2 | Fix in next release cycle or following |
| P3 | Backlog (lower priority, address when resources allow) |
| P5 | Won't fix, but accept patches (nice-to-have) |
| -- | Unknown: Not enough information |
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.
Always exclude bugs belonging to core security groups from search results.
When a bug is assigned to a component owner, this can be a strong signal of the bug's relevance and severity. Component owners are typically responsible for triaging and fixing bugs in their assigned components, so if a bug is assigned to a component owner, it may indicate that the issue has been recognized as significant enough to warrant their attention.
When analyzing a bug, check if it is assigned to a component owner. If it is, note the name of the component owner and consider this as part of your assessment of the bug's severity and impact. You may also want to look up the component owner's history of handling similar bugs to gain insights into how they might approach this issue.
The following components and their owners may be relevant for bugs in the graphics and media areas. This is not an exhaustive list, but rather a reference for common components and their owners. Always refer to https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html for the most up-to-date information on component ownership.
| Component | Owner(s) |
|---|---|
| Graphics | Bob Hood (bhood@mozilla.com) |
| Graphics: Canvas2D | Lee Salzman (lsalzman@mozilla.com) |
| Graphics: CanvasWebGL | Ashley Hale (ahale@mozilla.com) |
| Graphics: Color Management | Ashley Hale (ahale@mozilla.com) |
| Graphics: Image Blocking | Andrew Osmond (aosmond@mozilla.com) |
| Graphics: ImageLib | Timothy Nikkel (tnikkel@mozilla.com) |
| Graphics: Layers | Bob Hood (bhood@mozilla.com) |
| Graphics: Text | Lee Salzman (lsalzman@mozilla.com), Jonathon Kew (jfkthame@gmail.com) |
| Graphics: WebGPU | Jim Blandy (jimb@mozilla.com) |
| Graphics: WebRender | Glenn Watson (glennw@mozilla.com) |
| Web Painting | Timothy Nikkel (tnikkel@mozilla.com) |
| Audio/Video | Jim Mathies (jmathies@mozilla.com) |
| Audio/Video: cubeb | Karl Tomlinson (kthompson@mozilla.com) |
| Audio/Video: GMP | Jim Mathies (jmathies@mozilla.com) |
| Audio/Video: MediaStreamGraph | Karl Tomlinson (kthompson@mozilla.com) |
| Audio/Video: Playback | Jim Mathies (jmathies@mozilla.com) |
| Audio/Video: Recording | Karl Tomlinson (kthompson@mozilla.com) |
| Audio/Video: Web Codecs | Paul Adenot (paul@paul.cx) |
| WebRTC | Michael Froman (mfroman@mozilla.com) |
| WebRTC: Audio/Video | Jan-Ivar Bruaoey (janivar@mozilla.com) |
| WebRTC: Networking | Byron Campe (byronc@mozilla.com) |
| WebRTC: Signaling | Nico Grunbaum (nico@mozilla.com) |
If, based on the above list of components, a report appears to be misclassified (e.g. a media-related bug assigned to an unrelated component), suggest a reassignment to the correct component. This can help ensure that the bug is triaged and addressed by the appropriate team.
When suggesting a component reassignment, provide a clear rationale for why the current component may not be appropriate and why the suggested component would be a better fit based on the information available in the bug report. For example:
The issue described in this bug appears to be related to media playback, but it is currently assigned to the "Graphics: Layers" component. Based on the description and any attached test cases, it seems more appropriate for this bug to be assigned to the "Audio/Video: Playback" component, which is responsible for media playback issues. I recommend reassigning this bug to "Audio/Video: Playback" to ensure it is triaged and addressed by the correct team.
The following information may or may not be present in a bug, but when it is, it is useful for analysis.
core-security, this is a security bug.sec-(rating) keyword format.csectype-(type) keyword format.reporter-external keyword.about:support data may be posted in a comment or as an attachment. When detected, follow the extraction procedure below.
A comment contains about:support data if it includes any of these markers:
When about:support data is detected, re-fetch that comment using a targeted WebFetch prompt to extract the following verbatim — do not summarize:
Extract the following fields exactly as they appear, quoting values verbatim:
- Firefox version
- Operating system and version
- RAM (total system memory)
- GPU/graphics adapter name and driver version
- All crash report IDs (format: bp-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) — list every one
- All installed extensions (name and version)
- Any preferences listed as non-default or user-modified
- Any features listed as blocked or disabled (e.g. blocked GPU features)
- Any error log entries
Do not paraphrase. If a field is absent, say "not present".
bp-* IDs into Socorro lookup to assess crash volume, signatures, and recurrence. This is high-priority data.An S2 rating should be a high bar, reserved for issues that are clearly severe and impactful based on the information provided. An S1 rating should be an even higher bar, reserved for issues that are catastrophic in nature and have a very high impact on users. Be very critical of the information provided, and do not hesitate to conclude that the issue does not meet the criteria for S1 or S2 severity if the information is unclear, incomplete, inconsistent, or does not indicate a severe impact on users.
The following are a list of S2-rated reports found across the graphics components that have been accepted as that severity, corrected and marked as RESOLVED. These may be useful for comparison during this confidence check:
Note that some of these may be security-sensitive and may not be accessible without appropriate permissions. If you fail to access them due to permissions, prompt the user to provide an API key with the necessary permissions to access security-sensitive bugs. If the user provides an API key, use it for all subsequent Bugzilla API requests in the current session. If the user chooses not to provide an API key, note that security-sensitive information will be inaccessible for this analysis.
In order to see the difference between a properly categorized S2 and a properly categorized S3, you may also want to review some S3-rated bugs in the same components:
After processing these examples for training purposes, you should cache the results to the project memory for quick reference during subsequent triage sessions.
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.
A bug is considered security sensitive if it belongs to a security group (e.g. core-security) or has a security rating keyword (e.g. sec-critical, sec-high, sec-moderate, sec-low).
If the bug is security sensitive, inform the user:
This means it has been identified as having potential security implications. Please exercise caution when analyzing and sharing information about this bug.
If there is a failure to access a security-sensitive bug due to permissions, prompt the user to provide an API key with appropriate permissions to access security bugs. If the user decides to provide the API key, the key should be used for all subsequent Bugzilla API requests in the current session. It should not be cached or stored beyond this session.
If the user decides not to provide an API key, note that security-sensitive information will be inaccessible for this analysis.
Based on the description of the issue in the first comment, and any additional information that arises from any subsequent discussion in the remaining comments of the bug report, make a qualitative assessment of the issues qualification for an S1 or S2 severity rating.
This will be a subjective evaluation of the clarity, completeness, and consistency of the information provided in the bug report and its comments, as well as the nature of the issue being reported. The goal is to determine whether the information provided supports a conclusion that the issue is severe enough to warrant an S1 or S2 rating, or if it appears to be less severe based on the available information.
The first comment should provide a clear description of the issue and its impact on users, along with any reproduction steps or test cases that demonstrate the issue. Subsequent comments may provide additional information, clarification, or evidence that can help to further assess the severity of the issue. If this is missing (e.g., the entry is blank, or only provides a link to an external resource), this may be a red flag that the issue does not meet the criteria for S1 or S2 severity, as it may indicate a lack of clear information about the issue and its impact on users.
Factors to be considered in this evaluation should be based on the following questions:
Is there a clear description of the issue and its impact on users?
Are there clear reproduction steps or a test case that demonstrates the issue?
Is there a crash signature or other objective evidence of the issue?
Are the symptoms severe enough to warrant an S1 or S2 rating (e.g. data loss, major functionality impairment, high user impact)?
Is the information consistent across comments, or are there contradictions or gaps?
Are any workarounds mentioned in the discussion, and if so, are they satisfactory or do they still leave users with a severely impaired experience?
Is there any indication of the issue being security-related (e.g. "allows remote code execution", "exposes user data")?
Based on the confidence check, make an initial assessment of whether the issue appears to meet the criteria for an S1 or S2 severity rating. This assessment should be based on the information currently available in the bug report and its comments, and should be clearly communicated as an initial assessment that may be subject to change as more information is gathered.
S1 — If the issue appears to be catastrophic, with no workaround and high user impact, it may warrant an S1 severity rating. This would indicate that the issue blocks development or testing, affects a large percentage of users, causes data loss, and is highly likely to lead users to switch products.
S2 — If the issue appears to be serious, with no satisfactory workaround and significant user impact, it may warrant an S2 severity rating. This would indicate that the issue impairs major functionality and may cause users to switch products.
S3 or lower — If the issue does not appear to meet the criteria for S1 or S2 severity based on the information provided, it may be more appropriate to classify it as S3, S4, N/A, or --. Consider requesting additional information if there are gaps that could clarify the severity.
At this point, you should have enough information to form a preliminary assessment of the issue's severity. You may should end the analysis here. Summarize your findings and provide any recommendations for next steps (e.g. requesting additional information, marking as duplicate, etc.) before exiting the skill.
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).
Firefox bug triage assistant for media, web conferencing, and graphics related issues.
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.
Launch a local web server and open a browser page listing all bug triage reports in ./reports, with live JS text filtering.