Sign in Try the live demo

Use case

Review AI agent output with Patchrooms

Your agent loop just produced a new build: a preview deploy, a rendered artifact, a page nobody asked a human to look at yet. Someone still has to look at it. Patchrooms is what that person clicks on: one script tag on the live preview turns a plain "this looks wrong" into a structured report the loop can read back and fix.

Try the live demo

The problem

A good agent loop is a multiplier. One prompt becomes ten iterations, one task becomes ten previews to check. The multiplier doesn't remove the review step, it moves it onto you. You're now the one clicking through several builds a day, and if your feedback is a Slack message or a screenshot with a red circle drawn on it, the agent has to re-read it the way a human would: guessing at which DOM element you meant, guessing at the URL, guessing at what "this" refers to. Every guess is a round trip you didn't need. Other tools stop at showing feedback to a person. Patchrooms turns the click into an instruction the agent can run: a DOM selector, a screenshot, the page URL, and your comment, packaged as a punch-list the next iteration reads directly.

The workflow

  1. Embed the widget on the build you want reviewed

    One script tag on the preview, staging, or local page: <script src="https://room.patchrooms.com/v1/patchrooms.js" data-project-key="pr_..."></script>. No build step, no separate review tool to open. The loop's own output is the surface people click on.

  2. The reviewer clicks and talks

    No account, free, unlimited: anyone with the link can open the widget, click the element that's wrong, and leave a comment typed or spoken (voice notes are auto-transcribed). Patchrooms captures the DOM selector, a screenshot, the page URL, viewport, browser, and any console errors at the moment of the click.

  3. Reports land in a room, not a chat thread

    Every report gets a status (new, triaged, in-progress, closed), so a pile of clicks turns into a queue instead of a scavenger hunt through Slack history.

  4. The agent pulls the report, not a paraphrase of it

    Copy agent feedback turns a report into a Markdown prompt block (selector, goal, constraints, screenshot reference) ready to paste into Claude Code, Cursor, Lovable, v0, or Bolt. Or skip the paste: an MCP server exposes list_reports and get_report (screenshots inline) so the agent reads the queue directly, and set_status to close reports it fixed.

  5. Re-run the loop, re-review the diff

    The next build goes back in front of the same reviewers on the same room. Fixed reports close; new ones join the queue. The loop keeps multiplying output. The review checkpoint keeps up because the feedback going in is already structured.

Example

A Lovable-built onboarding flow gets a new preview URL every time the loop runs. Instead of a teammate typing "the upgrade button is broken on mobile" into Slack, they open the preview, click the actual button, and say it out loud. Patchrooms captures the selector (`header > nav > button.cta`), the 375×812 viewport, a screenshot, and the transcribed comment, and files it as a new report. The agent's next turn pulls that report over MCP, sees the exact element and constraints, fixes the collision, and calls set_status to close it. Nobody translated a bug report into a prompt by hand.

Agent-ready export

Two ways to get a report in front of the agent, both agent-ready by default: nobody manually rewrites what a reviewer said into something a model can act on: Copy agent feedback: from the dashboard, one click turns a report into a Markdown prompt block (selector + goal + constraints + screenshot reference) sized to paste straight into a chat with Claude Code, Cursor, Codex, Windsurf, Cline, or a builder chat like Lovable, Bolt, v0, or Replit Agent. MCP server: for loops that run without a human pasting anything, an API key (`pr_sk_*`) gives an agent list_reports and get_report (screenshots inline) to read the queue, and set_status to close reports once fixed. Reading and closing are real today; native Slack, Linear, or Jira connectors aren't shipped. If you don't want reports leaving your machine at all, `storage: 'local'` skips the network entirely (zero requests, no key, no signup) and reports export as Markdown or JSON for you to feed the agent yourself.

A report exports as Markdown like this:

## Patchrooms feedback (Room: onboarding-preview, 2 open reports)

### 1. Upgrade button overlaps nav on mobile
- Selector: `header > nav > button.cta`
- Page: https://preview-8291.vercel.app/onboarding
- Viewport: 375x812 (mobile)
- Browser: Safari 17, iOS
- Console errors: none
- Screenshot: https://app.patchrooms.com/blob/6f2a91
- Comment (voice, transcribed): "On mobile the Upgrade button sits right on top of the nav bar. You can't tap either one without hitting the wrong thing."
- Status: new

Goal: Fix the layout collision between `.cta` and the nav bar at mobile widths.
Constraints: Don't change desktop layout. Keep the button inside the header. Don't move it into the menu.

### 2. Step 3 form submits with empty email field
- Selector: `form#step-3 input[name="email"]`
- Page: https://preview-8291.vercel.app/onboarding?step=3
- Viewport: 1440x900 (desktop)
- Browser: Chrome 126
- Console errors: `TypeError: Cannot read properties of null (reading 'value')` at OnboardingStep3.tsx:42
- Screenshot: https://app.patchrooms.com/blob/6f2a92
- Comment: "Left email blank and clicked Continue, it just moved to step 4 anyway. Should block until email is filled."
- Status: new

Goal: Add required validation on the email field before allowing step 3 to advance.
Constraints: Match the existing validation pattern used on step 2's name field. Fix the null-read crash regardless of the validation fix.

FAQ

Does the reviewer need to sign up for anything?
No. Reviewing is free and unlimited with no account. Only the person triaging reports in the dashboard needs one.
What does a click actually capture?
The DOM selector of the element clicked, a screenshot, the page URL, viewport, browser, any console errors present, and the reviewer's comment, typed or a voice note, auto-transcribed. Each report also gets a status: new, triaged, in-progress, or closed.
How does my agent loop actually receive this feedback?
Either you copy a ready-made Markdown prompt block per report (selector, goal, constraints, screenshot reference) into your agent chat, or the agent reads the queue itself over MCP with list_reports and get_report, then calls set_status to close what it fixed.
Does this replace code review?
No. It's the checkpoint before code review even starts: someone looking at what the agent actually rendered, not the diff. Broken UI, wrong copy, and missed states show up here before a PR is anywhere near ready.
Can I review agent output without sending anything to the cloud?
Yes. storage: 'local' makes zero network requests, needs no key or signup, and exports reports as Markdown or JSON for you to hand to the agent directly.
Does it work with builder tools, not just coding agents?
Yes, the same script tag works on previews from Lovable, Bolt, v0, and Replit Agent, as well as builds you're iterating on with Claude Code, Cursor, Codex, Windsurf, or Cline.