Dev Briefs

A client writes "this looks weird on mobile". A few seconds later, under their words, a short brief appears that a developer, a Jira card, or a coding agent can act on: a one-line title, two sentences naming the element and the likely cause, an optional fix, and the facts the widget captured. The client's words are never rewritten, and clients never see the brief.

What a Brief Contains

Where It Comes From

When someone clicks an element and leaves a comment, the widget already records the element (tag, id, classes, text), how it was rendered at that moment (computed style, its box and its parent's box), the device (viewport, screen, pixel ratio, browser, OS, language), the page, and a screenshot. The brief is written from that data plus the comment text.

Nothing else goes to the model. Names, emails, replies, and other comments are never sent.

Console Errors

When a visitor leaves a comment, the widget also saves the JavaScript errors that happened on that page before the click: console.error calls, uncaught exceptions, and unhandled promise rejections. Never console.log or warnings. The last 10 errors are kept, each with its message, the script it came from with line and column, and how long after page load it happened.

Developers see them under Technical info on the dashboard card, on the board, in the widget drawer, and in the WordPress plugin inbox, as a count that opens the full list with a Copy all button. The brief reads the five most recent and, for a behaviour report ("the button does nothing"), names the one error most likely behind it with its file and line instead of guessing at a cause.

Before anything leaves the page, query strings and hashes are stripped from script URLs and anything that looks like a key, token or email address in the message is replaced with [redacted]. Errors from browser extensions and from the widget itself are dropped. Like briefs, console errors are for your team only: clients never receive them anywhere, including the REST API and MCP.

The Chrome extension only sees errors from the moment it loads on a page, not the ones before.

When a Brief Is Skipped

Not every comment is a task. Approvals ("looks good"), thanks, questions aimed at a person, and comments too unclear to turn into work get no brief and show nothing. There is no empty box: if a comment has no brief, the card looks exactly as it did before.

Who Sees It

Briefs are for the people doing the work. Workspace admins and team leads see them on the dashboard, on the board, and in the widget. Clients never see a brief anywhere, including the REST API when called with a client scope, and MCP tools.

Reading and Editing a Brief

On the dashboard, the brief sits directly under the comment text. From there you can:

• Copy the brief, with the element facts, for a ticket or a chat message.
• Rate it helpful or not right. Ratings feed the quality review, nothing else.
• Edit the title, summary, or fix. Once a person edits a brief the model never overwrites it, and the label shows who edited it.
• Write again to regenerate an unedited brief, or Remove it.
• Write dev brief from the card menu for a comment that has none, for example one posted before the setting was on.

In the widget, the brief is a toggle beside Tech info. Right after you post a comment it opens on its own and fills in as the brief is written. It adds Highlight element, which pulses the element the brief is talking about on the live page, and the same helpful / not right thumbs as the dashboard.

If your project is connected through the WordPress plugin, or runs on Shopify, the brief knows that and points fixes at the theme, block, or plugin setting where they live rather than at raw CSS.

Settings

Under Workflow → Dev briefs on a project:

The same settings live under Default settings → Workflow → Dev briefs for what new projects start with.

Integrations

The card or message for a new comment goes out immediately, as before. A few seconds later, when the brief is ready, the integration updates what it already created:

Turn off Use the brief title in integrations to keep the original headline and only add the brief to the description.

Console errors travel with the new-comment card itself, not the brief update: Jira, Linear, GitHub, ClickUp, Trello, Asana and Monday get a short "Console errors" block (at most three entries, oldest first), Slack and Discord get one line naming the count and the latest error, the email integration gets the same lines under the comment text, and webhook payloads carry the full list under metadata.consoleErrors.

API and AI Agents

Comments returned by the REST API carry a brief object once one exists:

{
  "brief": {
    "status": "ready",
    "title": "Hero heading overflows its container at 375px",
    "summary": "The .hero h1 is a fixed 48px, so on phone widths the last word wraps under the CTA button.",
    "suggestedFix": "font-size: clamp(28px, 7vw, 48px) on .hero h1",
    "kind": "layout",
    "confidence": "medium",
    "generatedAt": "2026-09-02T09:41:12Z"
  }
}

status is pending while the brief is being written, ready when it exists, paused when the account's allowance is used up, and skipped or failed otherwise. editedBy and editedAt appear when a person changed it.

The AI Agent (MCP) tools return the same object: list_comments includes the brief title and kind, and get_comment the full brief. An agent should read the brief first, since it already names the element and the likely change. The dashboard AI Assistant also sees briefs when answering questions about your feedback.

Console errors come along the same way. The REST API returns metadata.consoleErrors with include=metadata_full (and metadata.consoleErrorCount always), get_comment includes the full list, and list_comments items carry consoleErrorCount so an agent knows which comments are worth opening:

{
  "metadata": {
    "consoleErrors": [
      {
        "kind": "uncaught",
        "message": "TypeError: Cannot read properties of undefined (reading 'variantId')",
        "source": "https://example.com/assets/cart.js",
        "line": 120,
        "col": 14,
        "at": 4213
      }
    ]
  }
}

kind is console, uncaught or rejection; at is milliseconds since the page started loading.

Plans and Allowance

Briefs are included on every paid plan with no limit. Trials include 20 briefs. When the 20th is written, later comments show a small paused line with an upgrade link, and one email goes out. Briefs paused during the last week of a trial are written automatically once the account is on a plan.

Only briefs that are actually written count. Skipped comments cost nothing.