Make the frontend-triage agent response more concise

agents/README.md

@@ -63,7 +63,7 @@ the repo's root `docker-compose.yml`, so running it is three steps:
    ```dotenv
    # .env (repo root) — never commit this file
    ANTHROPIC_API_KEY=sk-ant-...
-   BUGZILLA_API_URL=https://bugzilla.mozilla.org
+   BUGZILLA_API_URL=https://bugzilla.mozilla.org/rest
    BUGZILLA_API_KEY=...
    ```
 

agents/frontend-triage/README.md

@@ -76,7 +76,7 @@ the secrets in a gitignored `.env` at the repo root:
 
 ```dotenv
 ANTHROPIC_API_KEY=sk-ant-...
-BUGZILLA_API_URL=https://bugzilla.mozilla.org
+BUGZILLA_API_URL=https://bugzilla.mozilla.org/rest
 BUGZILLA_API_KEY=...
 ```
 
@@ -109,7 +109,7 @@ they come from `.env`, `compose.yml`, or the command line.
 | `BUG_ID`            | yes      | The Bugzilla bug to triage                                                                                     |
 | `BROKER_URL`        | yes      | Bugzilla broker base URL; the agent appends `/mcp`. `compose.yml` sets it                                      |
 | `ANTHROPIC_API_KEY` | yes      | Drives the agent (billed per token)                                                                            |
-| `BUGZILLA_API_URL`  | yes      | e.g. `https://bugzilla.mozilla.org` — **broker container only**                                                |
+| `BUGZILLA_API_URL`  | yes      | e.g. `https://bugzilla.mozilla.org/rest` — **broker container only**                                           |
 | `BUGZILLA_API_KEY`  | yes      | **Broker container only**; reads only. The agent never sees it                                                 |
 | `MODEL`             | no       | Defaults to `claude-opus-5` (`DEFAULT_MODEL` in `__main__.py`); pinned so runs are reproducible and comparable |
 | `MAX_TURNS`         | no       | Hard cap on loop iterations — a runaway guard, cut off if hit                                                  |

agents/frontend-triage/hackbot_agents/frontend_triage/agent.py

@@ -147,14 +147,18 @@ class FrontendTriageResult(HackbotAgentResult):
     f"Markdown link built from the `{SEARCHFOX_PLACEHOLDER}` placeholder, which "
     "is expanded into a revision-pinned Searchfox URL when your comment is "
     "recorded:\n\n"
-    f"    [{_EXAMPLE_PATH}]({SEARCHFOX_PLACEHOLDER}/{_EXAMPLE_PATH})\n\n"
+    f"    [tabgroup.js]({SEARCHFOX_PLACEHOLDER}/{_EXAMPLE_PATH})\n\n"
     "- Write the placeholder **literally**. Do not put a revision, `tip` or "
     "`HEAD` in it, and do not write a searchfox.org URL yourself — you do not "
     "know which revision is being linked.\n"
     "- After it, give the repo-relative path, plus a line anchor when you know "
     "the line: `#1234`, or `#1234-1250` for a range. No `L` prefix.\n"
-    "- Use the path as the link text, without backticks — backticked text does "
-    "not render as a link.\n"
+    "- **Use the file name alone as the link text**, not the full path: the "
+    "path is already in the URL, and repeating it inline is most of what makes "
+    "these comments hard to read. Keep the full repo-relative path in the URL. "
+    "When two files you cite share a name, add just enough parent directory to "
+    "tell them apart (`Crossword/Crossword.jsx`). No backticks around the link "
+    "text — backticked text does not render as a link.\n"
     "- Leave the paths in the trailing ```json plan block as **bare paths** — "
     "that block is parsed by a downstream tool, and a link there would corrupt "
     "it.\n"

agents/frontend-triage/hackbot_agents/frontend_triage/prompts/system.md

@@ -34,7 +34,7 @@ Use **only** these tools for accessing Bugzilla, nothing else.
 
 # Source repository
 
-Your working directory is the Firefox source repository — the whole tree, desktop and Android in one checkout. You have Read, Grep, Glob, and Bash (read-only — do not modify files) to inspect it. Use this to localize the bug: find the modules, markup, styling, and prefs (often under `modules/libpref/init/all.js`) that govern the behaviour, and any existing tests that cover the area.
+Your working directory is the Firefox source repository — the whole tree, desktop and Android in one checkout. You have Read, Grep, Glob, and Bash (read-only — do not modify files) to inspect it. Use this to localize the bug: find the modules, markup, styling, and prefs (often under `modules/libpref/init/all.js`) that govern the behavior, and any existing tests that cover the area.
 
 Where to look, and what you will find there, depends on the bug's component. Every area and the trees it covers:
 
@@ -83,13 +83,13 @@ Use these to raise your confidence and precision — but you still cannot build
 
 # Delegating to the investigator subagent
 
-You have one generic subagent type: `investigator`. It has the same read-only tools you do (source repo + bugzilla read tools). **You write its full instructions dynamically** each time you spawn it — there is no fixed investigator behaviour.
+You have one generic subagent type: `investigator`. It has the same read-only tools you do (source repo + bugzilla read tools). **You write its full instructions dynamically** each time you spawn it — there is no fixed investigator behavior.
 
 Use it when:
 
 - An assessment requires deep source-code reading that would pollute your main context
 - You need a focused answer to a specific question ("where is the split-view group line drawn?")
-- You want to parallelise independent investigations
+- You want to parallelize independent investigations
 
 When you spawn an investigator via the Task tool, write a complete, self-contained prompt: what to look at, what question to answer, what format to return. The investigator has no memory of previous spawns.
 
@@ -134,7 +134,7 @@ Before calling any action tool, state in your response:
 - **What** action you are recording and **why** (cite the specific rule)
 - **Your confidence**: high / medium / low
 
-Record exactly one `bugzilla_add_comment` with your fix plan, ending with the severity block described below. That comment is the **only** thing you can write to a bug — you have no tool that changes a field, so a severity, keyword, status or resolution can only be _suggested_ in the comment for a human to apply.
+Record exactly one `bugzilla_add_comment` with your fix plan, ending with the severity sentence described below. That comment is the **only** thing you can write to a bug — you have no tool that changes a field, so a severity, keyword, status or resolution can only be _suggested_ in the comment for a human to apply.
 
 The tool is deliberately narrow, and a call outside what it accepts is refused with the reason (fix it and retry — a refused call records nothing, so it costs you nothing but the turn):
 
@@ -145,20 +145,17 @@ The `reasoning` parameter is required and stored alongside the recorded comment.
 
 # Severity in the comment
 
-End your comment with this block, exactly this shape, after the fix plan and separated from it by a horizontal rule:
+End your comment with the severity as its own final paragraph, on **one line**, exactly this shape:
 
 ```
----
-
-Suggested severity: S4
-<one or two sentences on the user impact that decided the level>
+Suggested severity: S3. Widgets show stale but non-destructive state on a newly opened tab, which is the default configuration for anyone with the crossword enabled; reloading the tab works around it.
 ```
 
+- **One line.** No horizontal rule above it, no heading, and no line break between the level and the reasoning. A rule and a stacked label turn one sentence into a section, which is how a short comment starts looking like a report. It still begins its own line, so keep the blank line before it.
+- The level is followed by a period and then the impact that decided it, in one or two sentences on the same line.
 - **Do not state the bug's current severity.** A reader has the field on screen, and a comment is permanent while the field is not — "currently S4" is wrong the moment somebody changes it.
-- The reasoning goes on the line directly below the level, with no blank line and no `Rationale:` label.
-- Keep the blank line _before_ the `---`. Without it the line above becomes a heading.
 - Do **not** put your confidence in the comment. It belongs in `severity_assessment` in the structured output.
-- **Omit the whole block, horizontal rule included, when your severity confidence is low or you could not assess severity at all** — an out-of-scope or unlocalized bug included. A level you are unsure of still reads as a judgment someone may act on, and a stray rule with nothing under it renders as an empty section.
+- **Omit the sentence entirely when your severity confidence is low or you could not assess severity at all** — an out-of-scope or unlocalized bug included. A level you are unsure of still reads as a judgment someone may act on.
 - Declare the severity **once**. Naming the level again in your analysis gives the reader two claims that can disagree, and a comment that does is refused.
 
 Always be **brief** and to the point. Developers have limited time. Do **not** record private comments — all developers on the bug need to see them, and a private one is refused.

agents/frontend-triage/hackbot_agents/frontend_triage/rules/areas/application-updater.md

@@ -1,6 +1,6 @@
 # Application updater
 
-`toolkit/mozapps/update/`. `.sys.mjs` modules (`AppUpdater.sys.mjs`, `UpdateService.sys.mjs`, `BackgroundUpdate.sys.mjs`), the XPCOM interfaces in `nsIUpdateService.idl`, and the C++ updater binary under `toolkit/mozapps/update/updater/`. Update behaviour is heavily driven by prefs under `app.update.*` and by the state written to the update directory, so read `common/` for the shared constants and status codes.
+`toolkit/mozapps/update/`. `.sys.mjs` modules (`AppUpdater.sys.mjs`, `UpdateService.sys.mjs`, `BackgroundUpdate.sys.mjs`), the XPCOM interfaces in `nsIUpdateService.idl`, and the C++ updater binary under `toolkit/mozapps/update/updater/`. Update behavior is heavily driven by prefs under `app.update.*` and by the state written to the update directory, so read `common/` for the shared constants and status codes.
 
 ## Tests