reading-measurements
Skill33 starsChanged 36 days agoApache-2.0View on GitHub
Read a number without being fooled by it: an exit code, a passing result file, a test count, a list size, a control run, a red or a green. Use before reporting any figure, before turning a test run into a verdict, before acting on 'N items are broken', and whenever two outputs or two counts of the same thing disagree.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- okgrit/done-is-a-claimword for word, first seen Nov 8, 2026
Other versions1 project uses a version of this.
Word for word · 1
- okgrit/done-is-a-claim★ 33100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- acceptance-designSkill
- checking-deliverySkill
- collecting-worker-resultsSkill
- debugging-with-evidenceSkill
- evidence-freshnessSkill
- executing-plansSkill
- implementing-with-testsSkill
- planning-changesSkill
- public-claimsSkill
- responding-to-reviewSkill
- resuming-workSkill
- reviewing-changesSkill
- using-done-is-a-claimSkill
- whose-redSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
If the answer is "exactly the same", the number alone does not distinguish the claim from its alternative.
- Distinctive: line 19
Use the relevant checks below to decide what the figure supports.
- Distinctive: line 69
Before acting on "N items are broken":
- Distinctive: line 76
Would this detector ever say no?: Run it on a case known to be clean.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Reading measurements
Wrong reports rarely lack a measurement. They read a real number as answering a question it never asked. Before you report, decide or spend anything on a figure, ask:
What would this same number look like if my claim were false?
If the answer is "exactly the same", the number alone does not distinguish the claim from its alternative. Seek a discriminating observation or control.
Reading any figure
Use the relevant checks below to decide what the figure supports. A limitation may invalidate an interpretation without invalidating the observation itself.
- An exit code is not a verdict. pytest exit 4 indicates a usage error,
such as a missing path; exit 5 indicates nothing was collected. Read the
collection and result summaries.
no tests randoes not establish a pass; investigate selection, setup and the change before assigning cause. - Capture the command's own exit code. In
cmd | tail; echo $?the status istail's in ordinary shell pipeline behavior. Capture the tested command's status before reading a saved log, or use the shell's pipeline status facility.set -o pipefaildetects a failing pipeline in shells that support it; its status is not necessarily the tested command's code. - Read the relevant artefacts. A result file, a CI summary, a log and a progress counter are separate claims about one run. When they disagree, the disagreement is the finding.
- A green names its tree. Quote the branch and commit with each code-run figure and say whether the working tree was dirty. A run on main measured main, not your change.
- Match the scope of a comparison: paths, flags, environment and relevant machine conditions, with clean trees and quoted commits. Rerun a narrowed command on both trees before comparing; use the full suite if order or shared state matters. Record unavoidable differences as limits. Matching test names alone does not establish the same failure or exclude extra reds.
- A result belongs to the revision measured. It remains historical evidence when main moves, but a claim about current main needs a fresh run.
- An all-positive detector needs investigation. The inputs may all be affected, or the detector may be wrong. Check a known-good case and inspect its classification before trusting the inferred failure rate.
- A count travels with its filter. Print the query, and every exclusion, with the total, including the unit counted: definitions, collected test cases and executed cases are different quantities. Investigate differences in filters, revisions, inputs and method before attributing a discrepancy.
- A returned value needs interpretation. An HTTP 4xx, an empty response, a constant column or a 0-byte file may be valid for one question and useless for another. Check contents and status; record size and modification time when emptiness or freshness matters to the claim.
- Capture the whole output to a file and read its tail from the file;
a live
| tailmay omit the cause and hide progress. - Agreement needs independence. Two numbers copied from one source agree with themselves.
- A timeout is an observation, not a cause. Record the deadline and last progress. Isolate tests under a wall-clock limit when useful, but preserve the original suite run: isolation can hide order or shared-state failures.
- A quiet log is not a stall. A pipe ending in
| tailprints nothing until the run exits. Check process state and progress before calling it stuck; CPU time alone does not distinguish useful work, waiting or a loop.
Acting on a count
A list size measures the selected set, not necessarily the broken population. Before acting on "N items are broken":
- Which filter produced this number? Quote it with the figure.
- Is it one kind of thing? Group the members by what they are about.
- Does one class dominate? Classify failures by cause and count each class. A large class is a lead for a shared mechanism, not proof that one fix covers every member.
- Would this detector ever say no? Run it on a case known to be clean.
A self-selected sample does not predict the rate of the whole list, and a larger denominator does not repair it; draw the sample differently.
A reportable figure
For a code-run figure, record its command, branch and commit, whether the tree was dirty, relevant summary and log path. Include scope and filters for counts, both runs for a comparison, and any limits or untested scope. Other figures need their source, date and method. If evidence is unavailable, omit the factual claim or explicitly attribute a report; do not present it as your measurement.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

