Critique Intake: Feedback That Arrives Already Debugged
Bug report widgets capture context. Critique Intake turns that context into investigated, agent-ready engineering work.
A user says “invoice download is broken.” That sentence is not a ticket. It is the start of an investigation.
The old workflow is familiar: support forwards a screenshot, engineering asks what browser, the customer disappears, someone checks logs, someone else asks whether it happened once or every time, and the issue finally becomes actionable after half a day of Slack archaeology.
Critique Intake exists because that middle layer is now the bottleneck. Teams already have forms, widgets, screenshots, session replay, Jira, Linear, GitHub issues, Slack alerts, and coding agents. What they often do not have is a clean path from “a real user hit something broken” to “an engineer or agent has enough context to start.”
The market already solved capture
The website feedback market is not empty. Usersnap records browser console errors and network requests with feedback items. Sentry User Feedback can attach screenshots and connect reports to Session Replay. Marker.io captures network activity and browser details for reported bugs, and its MCP positioning now lets AI agents read bug-report context.
That is good. It means the category has trained teams to expect more than a textarea. Modern bug intake should know the URL, browser, viewport, errors, failed requests, and what the user was doing before they complained.
But capture is not the same as triage. A folder full of screenshots, console logs, and network rows is still work waiting for a human. The developer still has to decide what happened, whether it is reproducible, who owns it, how urgent it is, and what prompt a coding agent should receive.
The wedge is not “we invented bug reports.” The wedge is turning bug reports into investigated engineering work inside the same loop that reviews and controls code.
| Layer | Typical feedback tools | Critique Intake |
|---|---|---|
| Capture | Message, screenshot, URL, browser/device metadata, console logs, network failures. | Message, URL, browser, viewport, recent clicks, console errors, failed fetch calls. |
| Clarification | Often generic: “add more details,” or handled later by support. | One focused follow-up based on the report, before the user leaves. |
| Triage | Usually a human support or engineering step. | Type, severity, confidence, likely owner, evidence, reproduction steps. |
| Engineering handoff | Create Jira, Linear, GitHub, or Slack item with attached context. | Create an agent-ready prompt that can feed Builder, a coding agent, or an issue tracker. |
| Code-control loop | Usually ends at ticket creation unless connected manually. | Leads into Review runs, Change Passports, and Merge Gate API when a fix becomes a PR. |
Market examples based on public Usersnap, Sentry, and Marker.io docs accessed June 23, 2026.
Why bug intake matters more in the agent era
AI coding agents changed the economics of fixing small bugs. A well-scoped issue that used to sit in a backlog for a week can now become a draft patch in minutes. The limiting factor is not always implementation. It is whether the report is specific enough for an agent to avoid guessing.
“Download is broken” is a bad agent prompt. “On /billing/invoices, Chrome desktop, invoice #928, GET /api/invoices/928/download returned 500, console shows Failed to fetch PDF, user says this happens every time for older invoices” is a real task.
That is the gap Critique Intake closes. It starts before the PR, before the review, before the Change Passport. It transforms user pain into a clean unit of engineering work, then lets the rest of Critique do what it already does: run agents, review changes, preserve evidence, and decide what can merge.
What ships now
The first version of Critique Intake is intentionally narrow and useful. It is not a giant support suite. It is a working intake layer for software teams that want better bug reports without adding another heavyweight workflow system.
- A small script adds a Report issue button to your app.
- It asks for the user report, then one focused follow-up.
- It captures URL, browser, viewport, console errors, failed fetch calls, and recent clicked elements.
- Reports are classified by type: bug, UX confusion, missing feature, data issue, permission issue, billing/account, security, or unknown.
- Severity, confidence, evidence, likely owner, reproduction steps, and suggested action are generated immediately.
- Reports land in Dashboard → Intake.
- Operators can copy the generated Critique prompt, mark status, or queue work.
- The handoff is written for engineering action, not support bookkeeping.
Install and submit
<script
src="https://critique.sh/intake/widget.js"
data-project-id="PROJECT_ID"
async></script>The benefit is less ambiguity
The product benefit is not “AI wrote a summary.” The benefit is that engineering receives less ambiguity. Every useful intake packet should answer five questions quickly: what happened, where it happened, what evidence exists, who probably owns it, and what the next action should be.
The same user report becomes a different kind of work item.
| Raw feedback | Critique Intake packet | |
|---|---|---|
| User says | “The invoice download is broken.” | “Invoice download fails every time for older invoices.” |
| Technical context | Maybe a screenshot if the user added one. | URL, Chrome desktop, viewport, console error, failed request, recent clicks. |
| Engineering value | Someone still has to investigate the report. | Likely Billing backend issue with reproduction steps and evidence. |
| Agent readiness | Too vague; high chance of guesswork. | Specific prompt with failing endpoint, page, symptoms, and verification instruction. |
That matters for small teams because every vague issue steals senior attention. It matters for support teams because customers feel heard faster. It matters for agent-heavy teams because coding agents are only as good as the task they receive.
Why this belongs in Critique
Critique already lives at the boundary between generated code and shipped code. We review PRs, preserve Change Passports, run Remedy, expose the Coding Agent API, and provide the Merge Gate API for orchestrators. Intake moves the starting line earlier.
A user report is often the earliest signal that production reality and repository intent have drifted apart. If that signal is captured cleanly, it can become a fix prompt. If the prompt becomes a PR, Critique can review it. If the PR is risky, the Change Passport records why. If the fix is verified, the proof stays attached to the change.
That is the loop we care about: user complaint to investigated work, investigated work to patch, patch to evidence-backed review, review to merge decision. Intake is not replacing the existing Critique platform. It feeds it better tasks.
User report → investigated packet
Clarify, capture context, classify, and prepare the agent handoff.
Packet → implementation attempt
Use the generated prompt to run a repo-backed agent job.
Patch → evidence-backed verdict
Review the resulting PR with findings, severity, and evidence.
PR → controlled change
Preserve provenance, risk, evidence, policy, proof, and timeline.
How to compare it with existing tools
Use Usersnap, Marker.io, Sentry, Ybug, Loom, Canny, Featurebase, Intercom, Linear forms, or Jira forms when they fit the job. Critique Intake is not pretending those products do not exist. The question is where your team feels pain.
- 1Do you mainly need visual annotation and client approvals?Use a visual feedback suite. Screenshots, annotations, and project-management integrations are the center of that workflow.
- 2Do you mainly need production error correlation and replay?Use an observability tool such as Sentry. Error events, stack traces, and replay belong close to monitoring.
- 3Do you mainly need a public roadmap or voting board?Use Canny, Featurebase, or a similar feedback-board product.
- 4Do you need bug reports to become engineering or agent work fast?Use Critique Intake. Its center of gravity is the investigated handoff into the code-change loop.
The market is moving toward agent-readable bug context. Marker.io’s MCP positioning is a sign of the direction: context should not just be visible to humans; it should be usable by agents. Critique Intake starts from that same premise, then connects the output to Critique’s review and change-control system.
What comes next
The obvious next layers are screenshots with consent, richer request capture, source-map aware stack traces, dedupe against known reports, Linear/GitHub/Jira creation, Sentry correlation, and one-click agent runs. Those are useful. They are not the first principle.
The first principle is simpler: stop letting the most important production signal arrive as an unstructured sentence. Ask the right follow-up while the user is still there. Preserve the evidence. Hand engineering a packet that can move.
Try Critique Intake
Install the widget, send a test report, and inspect the triaged packet in Dashboard → Intake. The docs include the snippet, API payload, captured context, and how it connects to Builder, Review runs, Change Passports, and the Merge Gate API.
Read the docs