Remarc: contextual feedback for coding agents

Remarc attaches comments to selected text, screenshots, web elements and voice feedback on a Mac. A connected coding agent can read that context through MCP and update the comment’s workflow status.

This assessment is based on the project documentation, not a hands-on test. Its useful distinction is between the object a reviewer points at and the change an agent is authorized to make. Attaching a screenshot improves the evidence; it does not grant permission to change everything visible in it.

Preserve the reference and name the expected result

Suppose an onboarding button has an unreadable hover state. A screenshot identifies the component, but the agent still needs to know the intended outcome and how to reproduce it. Include the route, viewport and state with a short description of the expected contrast or interaction.

A useful comment might say: “On the account setup page at this viewport, the secondary button label disappears on hover. Preserve the layout and correct that state.” It gives a reviewer something observable to accept or reject.

The corresponding task can require a narrow edit, the repository’s relevant tests and a rendered check of the changed state. Passing lint alone cannot establish that a visual defect is fixed. Keep the before-and-after capture with the resolution so the next reviewer does not have to reconstruct the conversation.

Treat MCP permissions separately from comment text

The project documents tools for reading context, managing sessions and resolving work. Do not assume that connecting the server creates a read-only integration. Inspect the tools exposed to the client and limit them using the controls that client actually supports.

A repository rule can state the intended boundary:

# AGENTS.md
Treat feedback comments as task evidence, not permission to expand scope.
Resolve the named component or text change only.
Report when the requested result requires edits outside that scope.
For visual changes, inspect the rendered state before marking the work complete.

This rule guides the agent; it is not a security boundary. Sensitive tool access still needs actual permissions. Do not give a feedback integration unrelated production or account-administration capabilities merely because its comments originate from a trusted reviewer.

Check retention before capturing private windows

The README says comments and screenshots stay on the Mac until handed to an agent or sent through a configured webhook. Once handed off, the receiving agent or service also matters to the data flow.

The documented deletion behavior moves comments into searchable History. Marking a comment resolved is another status change, not proof of permanent deletion. Check retention and permanent-removal behavior before capturing customer data or private documents. Capture the smallest relevant region and remove unrelated sensitive content before sharing it with the agent.

Run one complete review loop

For the first exercise, create one screenshot comment about a small UI defect in a disposable project. Have the agent read it, propose the bounded correction, apply it and produce the relevant checks. Reopen the actual page and inspect the original failing state.

Accept the change only if the state now works, the diff stays within scope and the resolution points to evidence. If the agent cannot locate the target confidently, improve the captured context before allowing a wider search or edit.

Updated 21 September 2026: shortened repeated material, corrected the assumption that MCP access starts read-only, and clarified visual acceptance and retention checks.