Paste a repository URL. You get a report on what installing it would actually do: what the install path executes, whether published checksums are ever verified, and what gets written into your agent's configuration.
Accepts a GitHub URL, owner/repo, a commit or branch URL, npm:name or pypi:name. Verdicts are public.
Does an installer exist, does the release publish checksums or signatures, and can the verification code actually run?
Hooks, skills, MCP registrations or plugin manifests that reach an agent's harness before any install step.
Does the registry entry bind the published files to the build that produced them?
Which environment variables and hosts the install path touches, and are any credential-shaped?
How concentrated are publishing rights, and what is the real lineage?
How much of what you would receive cannot be reviewed by reading it?
A handful of reports we picked to show the shape of one: what the annotations look like, what the chain of trust draws, what the install-path schematic looks like when there is an installer to draw. Not everything analysed and not an activity feed, just examples.
The site analysing itself: the transparency flex. Its own README names curl|sh installers as one of the patterns it looks for, and no probe here mistakes that mention for an instruction.
Installer runs with elevated privileges and never checks the checksums its own release publishes.
Ships hooks, a plugin manifest and ten skill definitions: agent config reaches a harness before any install step.
A Python build backend runs at install time, alongside Claude Code hooks committed in the same repository.
An MCP server registration, and a package manifest with no install-time lifecycle scripts at all.
The repo that started this: the tool exists because its own maintainer hesitated before installing it. Three Claude Code hook manifests reach a harness before any install step.