Reticle: A Runtime Proof Layer for AI-Written Web and Desktop Code

The gap Reticle targets: an agent that cannot see its own output

An agent that writes a feature has no way to observe the feature. It can read the diff it produced and it can run unit tests, but neither exercises the running application. The README frames the failure mode concretely: a silent 500 under a page that looks correct, a flow that used to work and now does not, mock data standing in for the real API. Screenshots do not close this gap because the interesting state is not visual. A response code, a store value, a console error and a route transition are all invisible to a vision model looking at a rendered page.

Reticle's stated audience is narrow and specific: coding agents and the engineers driving them. The README addresses the agent directly, in second person, and the install path is a prompt pasted into Claude Code, Cursor, Copilot, Codex, Windsurf, OpenCode or any MCP agent. That is unusual. Most developer tools document themselves for a human who will then configure an agent. Reticle documents itself for the agent, and treats the human as the person who pastes once and then types /reticle.

How the perception actually works: an SDK inside the page, an MCP server outside it

The mechanism described in the README is a dev-only SDK loaded into the running application. Once inside, it can read what the README lists as the network calls, the store, the console, the routes and the DOM. An MCP server sits alongside the agent and exposes those readings as tools, so the agent drives the real app and then queries what happened rather than inferring it.

The verdict model has three states, not two: pass, fail, or "couldn't tell". The third state is the interesting design choice. A binary checker forces a guess when it lacks evidence, and an agent that guesses is worse than one that abstains, because a wrong pass is indistinguishable from a correct one in the transcript. Reticle also returns a file:line alongside the verdict, which is what makes the loop closable: the agent fixes the named location and retries until the run passes.

Two constraints are stated plainly in the README badge row: dev-only and localhost-only, with app data staying local. That is a deliberate boundary. The SDK is not meant to ship, and the MCP server is not described as reaching a deployed environment.

Installing it: what the commands actually do

On Claude Code the README gives a two-line plugin path that registers the MCP server and the /reticle skill together:

/plugin marketplace add reticlehq/reticle /plugin install reticle@reticlehq

For agents the skills CLI reaches, the command is npx skills add reticlehq/reticle. The README warns that the client must be restarted afterwards, and calls this the single step most installs stall on, because the tools do not appear until the restart happens.

There is a direct CLI path that auto-detects the framework, installs the kit plus the build plugin, and registers the MCP server for every agent at once:

RETICLE_INSTALL_SOURCE=readme npx @reticlehq/server init

And a manual registration for Claude Code:

claude mcp add reticle -s user -- npx @reticlehq/server mcp

The README's position is that a config file is not an install. The skill is supposed to instrument the app, start the dev server if nothing is serving, open the app, drive one real flow, and return a verdict in the same turn without asking which framework or port. Whether that holds in practice depends on the skill reading your repository correctly, which is not something the supplied material lets me confirm.

The framework surface, and where the SDK has to be injected

The README lists React, Vue, Svelte, Preact, Astro and plain HTML on the web side, plus Electron and Tauri for desktop, across macOS, Linux and Windows. The npm package named in the badges is @reticlehq/react, which suggests React is the most developed path, though the README claims the wider list.

The build plugin is the part worth thinking about. Detecting a framework is easy; injecting an SDK into the right bundle at the right point is not, and it differs across Vite, Next, Astro and a plain HTML file with no bundler at all. A plain HTML app has no build plugin to hook, so instrumentation there has to happen another way. The README does not spell out that path, and I would want to see it before assuming parity across the listed frameworks.

Electron and Tauri add a second layer: the desktop shell and the web view inside it. The README lists them as supported without describing how the SDK reaches the renderer process or what it can see from the main process. That is a gap in the supplied material, not necessarily in the product.

The limitation that matters: a green run is not a proof

Reticle checks the flow that gets driven. If the agent drives the wrong flow, or drives the right one shallowly, the verdict reflects that scope and nothing wider. The README's own three-state model acknowledges this: "couldn't tell" exists precisely because the tool sometimes lacks the evidence to decide. An agent under pressure to report completion can read an inconclusive verdict as good news, and nothing in the mechanism prevents that. The README even instructs the agent to skip its one-line star request when verification failed or came back "couldn't tell", which shows the authors expect that state to occur in normal use.

There is also an environment constraint. Dev-only and localhost-only means Reticle cannot verify a deployed build, a staging environment behind auth, or behaviour that only appears under production configuration. If your bug lives in a CDN cache header or a production-only feature flag, this tool is the wrong instrument. And because the SDK is injected into the dev bundle, a misconfigured build plugin can leave the app running without instrumentation while the agent believes it is being observed. The README treats "installed" as meaning a verdict came back, not that a config file exists, which is the right definition but also means a silent instrumentation failure looks like a working install until the verdict is checked.

Reticle against Playwright and browser agents

The README anticipates the comparison directly. Playwright drives a browser and asserts on what the page exposes; a browser agent with a vision model looks at rendered output. Both work from outside the application. Reticle works from inside it, which is the actual difference in approach: the network calls, store and console are readable because the SDK is part of the running app, not because a driver is scraping the page.

That distinction has consequences in both directions. Playwright runs headless in CI and produces artefacts you can archive; Reticle is described as dev-only and localhost-only, so it does not fill that role. Playwright requires test syntax and a suite you maintain; Reticle's README says there is no test syntax, no screenshots and no vision model, which lowers the cost of asking a single question but gives you nothing to keep as a regression suite. If your need is a durable gate that runs on every pull request, Playwright is the better fit and Reticle is not trying to be it. If your need is an agent checking its own work before it tells you it is done, the outside-in tools are answering a different question.

Licence, maintenance and what to verify before you commit

The repository metadata reports the licence as NOASSERTION, while the README badge says Apache-2.0 plus FSL. Those do not agree, and the discrepancy is worth resolving by reading the LICENSE file in the repository before you depend on the SDK in a commercial codebase. The README also describes the SDK specifically as Apache-2.0, which may mean the licence differs between the SDK and other parts of the repository. I am not giving legal advice here; the point is that the two signals in the supplied material conflict and only the file itself settles it.

On maintenance, the release cadence visible in the metadata is roughly weekly through August and early September 2026, with v2.13.0 and v2.13.1 landing on the same day. Frequent minor releases mean the MCP tool surface and the skill instructions can shift under you, and any prompt or slash command you have tuned may need revisiting after an upgrade. The repository is not archived and the last push is recent relative to those releases.

Before adopting, verify three things in your own environment: that the SDK is genuinely loaded in the page the agent is driving, that the flow you care about is the flow that got exercised, and that the verdict reads pass rather than "couldn't tell". The README's own definition of a successful install is a green verdict from a real flow, so hold the tool to that standard rather than to the presence of a config file.

Editorial conclusion

Adopt Reticle if an AI agent writes user-facing behaviour in your React, Vue, Svelte, Preact, Astro or plain HTML app and you are tired of "fixed" verdicts over silent 500s, provided the app runs on localhost and you accept a dev-only SDK in the tree. Do not adopt it as a CI regression suite or as a substitute for unit tests; it is a dev-time check, not a gate. Before trusting a green run, confirm the SDK is actually loaded in the page you think it is, that the flow you care about was driven rather than skipped, and that the verdict was pass rather than "couldn't tell", because the documentation treats that third state as a real outcome and an agent may report it as success.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. reticlehq/reticle on GitHub