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.
Dev briefs are on by default for every project. Turn them off, or tune them, per project under Workflow → Dev briefs.
What a Brief Contains
| Part | Example |
|---|---|
| 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. |
| Likely fix | `font-size: clamp(28px, 7vw, 48px)` on the heading, or let the container wrap. |
| Facts | The element selector, viewport, browser, and page, taken from the comment itself. |
| Kind | layout, copy, link, visual, behavior, or other |
| Confidence | high when the captured data confirms the problem, medium when it is consistent with it, low when inferred mostly from the words |
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.
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:
| Setting | What it does |
|---|---|
| Write a dev brief for new comments | The master switch. On by default. |
| Include a suggested fix | Adds a likely CSS or copy change. Turn off if you'd rather the brief only describe the problem. |
| Use the screenshot | Sends the comment's screenshot along with the element data. Better briefs for visual issues, a little slower. |
| Brief language | Free text. Type the language or style your team reads, for example "English", "Estonian", or "German, formal". Clients can keep writing in any language. |
| Use the brief title in integrations | Once the brief is written, connected tools retitle their card with it (see below). |
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:
| Integration | What happens |
|---|---|
| Slack, Discord | A threaded reply with the brief under the original message. The original headline is updated to the brief title. |
| Jira, Linear, GitHub, Trello, ClickUp, Asana | The card or issue is retitled and a "Dev brief" section is added to its description. |
| Monday | The item is renamed and an update with the brief is posted. |
| Webhooks | A second `comment` payload with `event: "brief_ready"` and a `brief` object, so your receiver can update by `commentId`. |
| Unchanged. The new-comment email is sent before the brief exists. |
Turn off Use the brief title in integrations to keep the original headline and only add the brief to the description.
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.
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.
Briefs are written by Claude and can be wrong. Treat them as a strong first read of the comment, not as a verified diagnosis, and correct them where it matters. Every brief keeps the original comment intact right above it.