Skip to content
Vroxy docs

Feedback to fix

The widget isn’t only for your customers. When one of your admins is looking at a broken page in your own app, they can file feedback about it from the same chat window — with the page, the element and the render trail already attached — and hand it straight to a coding agent.

This is a loop: notice it, file it, dispatch it, get a PR.

Filing feedback

Section titled “Filing feedback”

The feedback controls only appear for admins. On your own site, the Ruby gem loads an in-page inspector when the identified user’s role is one of config.admin_roles (admin and owner by default). Where the inspector isn’t present, the feedback menu stays hidden and the slash commands refuse. The Node, Python and WordPress packages don’t load the inspector.

With it loaded, there are three ways in:

The 💡 menu in the widget’s header, with two items:

  • 🎯 Inspect an element — collapses the panel and turns the page into an element picker. Click the thing that’s wrong, add a note, optionally capture a screenshot, submit.
  • 📝 Send a note — opens the note panel for a page-level comment with no element picked.

/inspect — same as the menu item. /inspect the button is misaligned pre-fills the note.

/note — files a page-level note. /note the total is wrong on mobile submits immediately; /note on its own opens the panel.

Filing switches the widget to the feedback’s own conversation, so any reply — from a teammate or from a dispatch agent — lands in the same window you filed from.

What gets captured

Section titled “What gets captured”

A note is capped at 4,000 characters. Alongside it:

  • Where you were — the full page URL, the path, and the controller#action that rendered it.
  • What rendered — the ordered list of partials Rails rendered for that request. This is the single most useful field when you’re hunting for which file to open, and it’s why the Rails gem captures it server-side rather than guessing from the DOM.
  • The viewport — width and height, so “only broken on mobile” is visible rather than guessed.
  • The element, when you picked one — a short CSS selector path, the tag name, its visible text (up to 500 characters) and its outer HTML (up to 4,000).
  • Screenshots, if you captured or pasted any. They’re attached to the ticket and shown on its page.
  • Who filed it — the visitor identity your identify() call supplied: name, email and role.

Everything lands as a ticket on your workspace’s Feedback page, with a linked conversation. Tickets move open → triaged → resolved, or are dismissed. Seeing them needs feedback.read; changing status or dispatching needs feedback.manage.

Two ways to act on it

Section titled “Two ways to act on it”

Both are code agents, configured on the Dispatch page — how they’re set up, what they target, and how their changes reach your repo is covered in Code agents. What follows is what each one does with a feedback ticket.

Which one should you use?

Section titled “Which one should you use?”

The Copilot path is the one to reach for if your code is on GitHub and your team already has Copilot: nothing to run, nothing to keep alive, and the output is a PR in the normal place. The dispatch-agent path suits a repository that isn’t on GitHub, or a workflow where you want the agent running against a working tree you control.

Neither replaces reading the ticket. Both give you a starting point with the page, the element and the render trail already attached — the context that usually costs you ten minutes of “which page was this again?”.