WAYS OF WORKING · APPLIED NINO CHAVEZ
Four checks that run before anything touches your machine: sort the evidence by who published it, hunt the one source arguing against its own interest, diff the feature list against your own setup, and read what the installer writes before you let it write.
→ or scroll to advance · ← to go back
02 THE FAILURE THIS FIXES
A good landing page blurs them on purpose. A star count, a feature table, a benchmark, and a wall of testimonials feel like four sources converging. Frequently they are one file, in one repository, written by one person.
What it feels like
Overwhelming agreement. Everything you read says the same thing, and the volume of it starts doing the work that verification should be doing.
What it is
One publisher, repeated. The sort that separates them takes minutes and does not require installing anything, running anything, or asking anyone.
Cost of skipping: you adopt on volume.
03 CHECK ONE · THE LEDGER
One row per claim that would move your decision. Four stamps. Be honest about the middle two — most piles come back mostly red, and that is what a product page is for.
Feature tables, benchmarks, capability lists
Written by the party that benefits from you believing them
A critical review the project quotes approvingly
Third-party, but it survived a filter someone else set
Star counts, download numbers, install metrics
Nobody wrote them — but they measure interest, not fit, and they are gameable
Anything you tried to read and could not
Record the attempt. A named hole is worth more than a plausible summary
gh api repos/<owner>/<repo> --jq '{
fork: .fork, parent: .parent.full_name,
stars: .stargazers_count, pushed: .pushed_at,
archived: .archived, license: .license.spdx_id
}'
04 CHECK TWO · ADVERSE INTEREST
When every source benefits from the conclusion it argues for, one category still carries weight: a party publishing something that costs it. For agent tooling, three places hold almost all of them.
The host platform's docs
If the tool runs on top of something else, read that something else. A platform documenting a limitation of its own feature has no reason to invent it — and this is where authentication and terms problems surface first.
The license file, not the badge
An unrecognized license renders as a non-answer rather than an error. A project describing itself as open source under a bespoke license is a fact worth surfacing before it touches client work.
The terms page itself
If reporting says a policy changed on a date, open the policy. If the clause is not there, label the claim as reporting. Do not drop it, and do not promote it.
Finish this sentence with something concrete: the claim that most changes my decision is ____, published by ____, who does not benefit from it. If you cannot, your decision currently rests entirely on material the vendor controls. the exit condition for check two
05 CHECKS THREE AND FOUR · MECHANICAL
Three · the inventory diff
Pull the tool's reference documentation rather than its README — the first enumerates, the second sells. Then mark every item covered, absent, or blocked.
Blocked is the bucket people skip and the one that matters: new, good, and unusable for a reason unrelated to quality. Then check the reverse — what does your setup do that the tool never mentions?
Prerequisite: your own side, written down.
Four · the collision check
Installers say what they write. Read that section, then compare against your machine before running anything: names it links into your path, config files it edits, and whether an uninstall exists.
Prefixed names and new named sections are additive and reversible. Bare names and rewrites of sections you already use are not. Look specifically for defaults governing concurrency, permissions, and approvals.
ls -1 ~/.local/bin # your names grep -nE '^\[' <the-config-it-edits> # your sections
If the install guide will not tell you enough to answer those, that absence is the finding. Installers that will not say what they write are the ones most worth not running.
06 START HERE
Minute 0
Run the identity command on whatever link you were sent. Confirm you are reading the live project and not a fork that stopped moving. This has caught a stale copy more than once.
Minutes 5–20
Build the ledger, then go hunting for one adverse-interest claim. Stop when you can name it and its publisher, or when you have established that none exists.
Minutes 20–40
Diff the inventory in both directions, then read the installer's own description of what lands on disk. Write a one-line verdict for names, config writes, and uninstall.