Site Redliner

The Problem

Reviewing a running web app with an AI agent means translating what you see into prose: "the third button from the left, the one that says—". There's no shared coordinate system, no way to point at the actual pixels, and no way for the agent to show you a change in place before you accept it. Design review, QA, and agent-driven iteration all stall on the same missing primitive — a way for a human and an agent to point at the same live page.

What I Built

A zero-dependency Node proxy that fronts any web app and injects a review overlay onto the real, running page — no framework, no changes to the target app. A human draws numbered annotation boxes directly on the live DOM and writes an instruction; an agent (Claude Code) reads and writes the same shared annotations JSON, posting proposals back as inline diffs with rationale. A keyboard-driven review panel triages both directions through a lifecycle (triage → queued → implemented), with threaded comments, per-item verify, and ticket-style export that bundles each item with its marked-up screenshot. All project data — config, annotations, exports — lives in a per-project workspace directory, never in the tool's repo.

Notable

The annotations JSON is the entire contract between human and agent: the human owns instructions, the agent owns proposals, and every item carries a stable id, an author, a lifecycle state, and a thread — so a review survives across sessions and neither side has to hold the other's context in its head. Because it proxies rather than embeds, it drops onto an app you don't control with zero integration — the shots above show it running over a proxied Google homepage. Built first to run design review on a client's product demo, then generalized and open-sourced under MIT; client data stays in the workspace directory and never touches the public repo.

Stack

Status

Open source at github.com/blaizew/site-redliner.