Use case · QA and support
A tester files what they saw; the agent receives what it needs. The console, the environment and the exact element travel with the report — so the first question back isn't “where exactly?”
File it by pointing at it.
On the page where the bug is, at the moment it's on screen. A severity and one sentence — the rest is captured for them.
Screenshot, selector, computed styles, HTML, console output, URL, viewport and platform. Nothing typed by hand, so nothing is missing an hour later.
Filter by open or fixed, by severity, by page. The team and the agent read the same list, so “is anyone on this?” stops being a question.
It greps the repo for the selector, lands the change and replies on the pin with what it did. QA accepts or reopens — the report closes where it was filed.
Everything a developer would have opened DevTools to collect is already in the ticket. The agent starts on the first read instead of the third.
Claude Code · via MCP: “Guarded the empty cart state in CartSummary.tsx — the console error was a null read. Commit 41b0e7.”
The first pin below reports an unreadable button on our demo product — with the selector, the measured contrast and the element's own screenshot attached, which is what an agent needs to find the code.
Open the Details on a pin to see the styles and HTML that travelled with it.
A bug report for an AI agent is an ordinary bug report with the browser context attached — the element, its computed styles, the console output, the URL and the viewport — in a form the agent can read directly rather than parse out of prose.
Traditional bug reports are written for a human who will reproduce the problem: they describe a path, and the reader opens DevTools to find the rest. An agent can't reproduce anything. It has the repository and whatever the report contains, so every detail left out of the report becomes a question, and every question is a round-trip.
In practice this changes who does the work of collecting evidence. The tester points at the failing element; the extension captures what a developer would have gathered by hand, and the agent receives it over MCP. The report stops being a description of the bug and becomes the bug's context.
No. They click the element that looks wrong. The selector and styles are captured for them.
Yes. Handoff runs in the browser, so it sees whatever page the tester is on — staging, production, or a page that needs a session.
Console output is captured with every pin, and a pin can be filed on the page as a whole rather than a single element.
It marks the pin resolved and writes what it changed. A person accepts or reopens — resolution isn't the agent's decision alone.
Not for this loop. Pins live on a board with severity and status. If you already have a tracker, the pin's page link and context paste into it cleanly.