Created and documented by Nino Chavez.

Applied A01 · 6 chaptersScroll to read · use ← → to step between chaptersSkip to the record

WAYS OF WORKING · APPLIED NINO CHAVEZ

Run the subtraction
before you install.

Four checks that run before anything touches your machine: enumerate what you already have, subtract it from what the tool ships, query the part of the repository nobody curates, and confirm the uninstall works.

or scroll to advance · to go back

02 THE FAILURE THIS FIXES

A feature list is half a subtraction

Fifty-four hooks is fifty-four against zero. Against a setup that has been accumulating for a year, the honest number is whatever remains after your own is subtracted — and nobody publishes that half for you, because it lives on your machine.

What it feels like

An impressive list of capabilities, each one plausible, adding up to an obvious yes. The volume does the work that measurement should be doing.

What it is

An unfinished equation. The same list produces a different answer for a person running stock tooling than for a person with a year of hooks and helpers already loaded.

Cost of skipping: you adopt on volume.

03 CHECKS ONE AND TWO · THE SUBTRACTION

Write your baseline down, then sort into three

Check one is the one people skip and the one that pays permanently: get everything your agent loads at startup into a list you can read. Do it once and every future tool question becomes a lookup.

Native

Your setup or your agent already does this — remove it from the gain column entirely

native

New

Genuinely absent. This is the delta, and the only column that argues for installing

new

Blocked

New but unusable for reasons unrelated to quality — wrong platform, broken upstream, needs a subscription you don't hold

blocked

Blocked is the bucket people collapse, and it distorts the answer both ways. A component that is excellent and unusable is not a gain, and it is also not a criticism of the tool. Then run it backwards: what does your baseline do that the tool's list never mentions?

pull the enumeration, not the sales page
curl -fsSL https://raw.githubusercontent.com/<owner>/<repo>/<branch>/docs/reference/features.md
ls ~/.claude/skills/ ~/.claude/commands/ ~/.claude/hooks/   # your side

04 CHECK THREE · THE UNCURATED HALF

Documentation says what it does when it works

The issue tracker says what it does on other people's machines. Users write it, and unlike a testimonial section it cannot be quietly pruned without the gap showing. Three queries: volume, arrival rate, and your own failure modes.

how much is open, and how fast is it arriving
gh api "search/issues?q=repo:<o>/<r>+is:issue+is:open&per_page=1" --jq '.total_count'
gh api "search/issues?q=repo:<o>/<r>+is:issue+created:>=<30-days-ago>&per_page=1" --jq '.total_count'
what users argue about most
gh api "search/issues?q=repo:<o>/<r>+is:issue&sort=comments&order=desc&per_page=25" \
  --jq '.items[] | "\(.comments)c \(.state) #\(.number) \(.title)"'

Read for shape, not counts — a high open count on a popular project mostly means it is popular. Does it break when its host releases? Search the host's version numbers. Do its own updates break things? Search after updating. Are the busiest threads features, or the same bug returning?

05 CHECK FOUR · THE EXIT

"Cheap to try" is a claim about uninstalling

Every installer is one command. The exit is the part nobody tests, and it decides whether being wrong costs you a minute or an afternoon.

Read what it writes

Install guides usually say what lands on disk. Check each location against your machine before running anything. Prefixed names and new named sections are additive and reversible; bare generic names and rewrites of sections you already use are not.

Then search for the uninstall

Almost nobody does this. Open reports that removal leaves things behind are worth more than the entire installation guide, because they tell you the true cost of being wrong.

No answer is itself the finding.

the query that retracts a recommendation
gh api "search/issues?q=repo:<o>/<r>+is:issue+uninstall+OR+cleanup+OR+remove" \
  --jq '.items[] | "\(.state) \(.created_at[0:10]) #\(.number) \(.title)"'

06 START HERE

One tool, four checks, forty minutes

Minutes 0–10

List what your agent loads at startup, and name what each item does in a sentence without looking it up. Anything you cannot explain is a finding — it loads every session and you do not know why.

Minutes 10–22

Pull the tool's reference enumeration and sort every component into native, new, or blocked. Then run it backwards. Count the new bucket — that count is the decision.

Minutes 22–40

Three tracker queries plus two searches specific to your platform and host version. Then the uninstall search. Write one sentence on the recurring failure mode and whether it would reach you.

a feature list is half a subtraction native · new · blocked the tracker is the half nobody curates check the exit before the entrance
Colophon. The technique behind demo 12, generalized off that session's specifics — including the part where an earlier version of this method skipped check three, concluded the evidence was thin, and had to be retracted. Check one assumes your setup is already written down; if it is not, that is the actual first task, and it is the same enumeration that makes every later comparison cheap. Related: verification as a discipline in demo 07, provenance labels for research output in the applied card, and auditing your own setup rather than someone else's in demo 11.

The reusable technique

Run the Subtraction Before You Install

Four checks that run before anything touches your machine: enumerate what you already have, subtract it from what the tool ships into native, new, and blocked, query the part of the repository nobody curates, and confirm the uninstall actually works. The technique behind demo 12.

Collection
Applied
Record
A01
Related sessions
1

Working principles

What to carry forward

  1. A feature list is half a subtraction.
  2. Sort the result into native, new, and blocked.
  3. Treat the issue tracker as the half nobody curates.
  4. Check the exit before the entrance.

Explicit relationships