Verify Unattended

Reticle, unattended

Same product, same verdicts, one difference: nothing here waits for a human.

The normal skill has two places where it hands control back: "restart your client so it picks up the MCP server" and "open the app in a browser". Both are correct when someone is sitting there. In goal mode they are dead ends: the restart ends the context holding these instructions, and there is nobody to open a tab.

So this skill takes the route that needs neither, and stops only when it has a verdict or a reason.

The one rule that makes this work

You cannot add MCP tools to your own running process. No slash command, no config edit, no re-registration reaches the tool list you already have. Your client read it before Reticle existed. Do not try, and do not ask to be restarted.

Instead, branch once on what you already have:

• reticle_* tools present → drive with them. Best evidence, source-mapped, full verdicts.
• not present → use the CLI. reticle verify produces a verdict and an exit code with no MCP involvement at all.

Both routes end in a verdict. Pick the one your process allows and go.

Step 1: wire it, once, quietly

export RETICLE_INSTALL_SOURCE=npx_skill
npx -y @reticlehq/server@latest init

The export is on its own line on purpose. Every other copy of this command carries the marker inline, but this skill runs where commands are matched against a prefix allowlist (see "Keep commands plain" below), and RETICLE_INSTALL_SOURCE=... npx ... no longer starts with npx. Inline, it would stop matching the very rule this file tells you to rely on.

Then read the report rather than assuming it. Two lines matter:

• ⚠ on the app's build config: the wiring did not land. Apply the printed edit yourself; do not carry on as if it had.
• ℹ naming a version fallback: the pinned SDK was refused and a different one installed. The SDK and the daemon must agree; if a later call reports a protocol error, this is why.

init is idempotent. A step reading already wired is a pass, not a skip.

If init reports every step already done, the app was instrumented before you arrived. That is fine, but it means this run has not proved the install. Say so rather than claiming you set it up.

Step 2: make sure the app is actually running

The daemon needs a page to look at, and a page needs a server. Do not ask whether to start one.

1. Read the dev script out of package.json.
2. Start it in the background, on the port the script implies.
3. Poll the port until it answers. A dev server that has to compile a route can take 30 seconds on first hit; a timeout here is not a failure yet.

If a server is already listening on that port, use it. Starting a second one on a different port gives you an app nobody is verifying, and leaves a process behind.

Restarting matters after init. A build plugin added to a config the running server already read is not in the bundle. If the server was up before step 1, restart it now or nothing you do next will find an instrumented page.

Step 3: get a page connected

With the MCP tools:

reticle_session { action: "list" }

A listed session is the proof. Nothing else in this skill can tell you anything about the app until one appears.

No session, and no human to open a tab? Take one yourself:

reticle_run { tool: "reticle_lease", args: { action: "acquire", url: "http://localhost:<port>/" } }

The lease opens a browser Reticle owns and drives. It is the whole answer to "there is nobody here to open the page".

Without the MCP tools, skip to step 4: verify opens its own browser.