touchstone

touchstone

!checklist init ${CLAUDE_SKILL_DIR} --force

A touchstone is the dark stone a jeweler rubs gold against to tell real metal from a convincing fake. touchstone is what you rub a repository against to tell genuine quality from the things that merely look like it — before you stake an afternoon, a dependency, or a production system on it. It is the second skill of the quarry suite: it owns evaluation — the fast, deliberate scan that turns a candidate into a verdict. It audits (and guides you to run) a gated pipeline, and it will not advance past a GATE until the checklist tool clears it. That gate enforces order — each glance before the next — not the substance of the judgment inside it; the tool structures the discipline, it does not supply it, so the calibration is yours.

The one mental shift everything hangs on — weight the signals that can't be faked, not the ones that can. The goal is not to read the project; it is to scan a handful of dashboards and form a fast "worth more of my time?" judgment. An agent is superb at this mechanically — it can pull the commit history, release cadence, issue timeline and contributor graph for fifty repos in seconds. But its instinct is to rank them by the star count and the README, and those are precisely the two signals that are cheapest to manufacture: stars can be farmed, and in 2026 a fluent, feature-rich README sitting on top of a thin or incoherent commit history is the signature of AI-generated slop. So touchstone inverts the convenience-ordering a tired human falls into: down-weight stars and README polish to suspect-until-corroborated, and up-weight the expensive-to-fake signals — whether the commits are real changes or padding, whether the maintainer actually responds in issues, the bus factor, the real downstream "Used by", and the presence of tests and CI. The verdict is built from what is hard to fake.

The agent is the means, not the oracle. Here it has two jobs: the dashboard reader (pull the real signals fast, from the actual repo) and the adversary (actively look for the tells that this is dead, abandoned, or slop). It is not the judge of whether the repo is right for you. Its gradient points at a confident, tidy verdict, and it will reach one by trusting the surface and filling gaps with plausible facts — asserting "actively maintained" from a high star count, or inventing a contributor statistic it never pulled. So one discipline is absolute: every claim traces to the actual repo. A number is read from the repo's data or it is not stated; "well-maintained" names the last-commit date and the issue-response pattern behind it, or it is not claimed; when a signal can't be determined, the verdict says unknown, never a guess dressed as a finding.

What you cannot delegate — the calibration. The agent can score the axes; only you can say what the score means for your situation, because the bar moves with the use. The same repo — a clever, fast, single-maintainer tool, last touched eight months ago — is a fine pick to try out for a weekend, a reasonable base to read and learn from, and a bad bet to make a load-bearing production dependency. Low activity is not automatically bad: a small, focused, Unix-style library can be "finished" and correctly sit untouched for years. The agent reports the signals; you decide whether they clear the bar your context sets. Hand it the calibration and you have automated a context-free verdict onto a context-dependent decision.

What "done" looks like — a calibrated verdict with its evidence, not a star-ranked list. The checkup is over when each target has a three-axis read (alive / healthy / well-built), each axis backed by the specific signals behind it, a slop-risk call, and a verdict calibrated to your use-context — deep-dive, try it, don't-bet-in-production, or skip — with every claim traceable to the repo. For a batch, that is a ranked, justified shortlist; for one repo, a go/no-go with reasons. The terminus is the judgment plus its evidence, not "the one with the most stars".