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

Run this only when the user's goal asks for Reticle or for a verified result: init changes package.json, the lockfile and the build config. Otherwise skip to step 3 and use the lease, which changes no file.

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: