CLI Finder

CLI Agent Readiness Scoring Methodology

See how CLI Finder measures automation readiness, operational risk, and evidence confidence separately without presenting documentation claims as execution tests.

Why There Is No Single Safety Score

A CLI can offer excellent JSON output, stable exit codes, and non-interactive authentication, making it easy for an agent to automate. The same tool can also include commands that delete repositories, apply infrastructure, or change production configuration. Collapsing these facts into one score hides the actual decision boundary.

CLI Finder therefore exposes Agent Readiness, R0–R3 risk for individual commands, and evidence confidence separately. Readiness asks whether the tool can be operated reliably; Risk asks what a command can change; Evidence asks what supports the claim.

Nine Agent Readiness Dimensions

Each dimension has a fixed weight for a total of 100. A registry entry earns points only for the evidence it currently contains.

Structured output
Use --json or --jq where supported and keep diagnostic logs on stderr.
Weight: 20/100
Headless operation
Official documentation describes a non-interactive authentication or execution path.
Weight: 15/100
Safety controls
CLI Finder separates read commands from commands that require confirmation.
Weight: 15/100
Determinism
Commands use explicit arguments and documented output controls where available.
Weight: 10/100
Authentication
Use a read-only or fine-grained token limited to the required repositories.
Weight: 10/100
Documentation
This entry cites official documentation checked on 2026-07-10.
Weight: 10/100
Installation
Official installation paths cover macOS, Linux, and Windows.
Weight: 8/100
Maintenance
An official source repository is linked for release and maintenance review.
Weight: 7/100
Agent artifacts
CLI Finder can generate registry-derived skills and policies; the tool itself was not credited with shipping them.
Weight: 5/100

R0–R3 Command Risk

Risk belongs to a concrete command, not a permanent label for the whole tool. The actual risk also depends on account, environment, arguments, and permissions.

R0Read-only or local observation
Usually eligible for automatic execution, while sensitive output and remote read access still need review.
R1Reversible local change
Record the change scope and recovery path; unknown writes are not R1 by default.
R2Remote state change requiring approval
Show the target, exact command, and impact and obtain explicit approval before execution.
R3Irreversible or production-impacting operation
Show the target, exact command, and impact and obtain explicit approval before execution.

Evidence Confidence and Promotion Rules

verified
Named checks were executed in a recorded version and environment.
docs-verified
Current official docs or repository material was reviewed without executing the complete path.
maintainer-submitted
A maintainer supplied the information; independent review or execution is still needed.
community-reported
The community reported an observation that has not been confirmed by the maintainer or an independent test.
unverified
There is not enough source evidence to use the claim for an automation decision.

Promoting an entry from Docs-verified to Verified requires the tool version, operating system or container, executed command, exit code, and the result relevant to the public claim. Failed checks remain part of the record rather than being hidden behind the successful path.

Verification can expire. Major releases, official documentation changes, broken installation paths, authentication changes, or community reports can trigger a new check. Without new evidence, the old date remains visible rather than being refreshed cosmetically.