assumption-audit
Skill7 starsChanged 3 months agoMITView on GitHub
Audit inherited values when an optimization plateaus.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- opelpleple/meta-skillstheir own version, first seen Oct 11, 2026
- kalshamsi/fable-discipline-skillstheir own version, first seen Oct 8, 2026
- hraness/personal-monorepo-templatetheir own version, first seen Sep 28, 2026
- Natan-Mohart/24-strategy-skills-for-claudetheir own version, first seen Aug 8, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- Natan-Mohart/24-strategy-skills-for-claude★ 41same name
- hraness/personal-monorepo-template★ 4same name
- kalshamsi/fable-discipline-skills★ 0same name
- opelpleple/meta-skills★ 0same name
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 repository25 other files it gives its agents.
- assess-ideaSkill
- attribute-mechanismSkill
- campaign-reviewSkill
- campaign-statusSkill
- cite-checkSkill
- claim-auditSkill
- correctness-suiteSkill
- debugSkill
- deriveSkill
- dimensional-analysisSkill
- discovery-loopSkill
- experiment-designSkill
- fork-campaignSkill
- frame-problemSkill
- handoffSkill
- improve-kitSkill
- literature-reviewSkill
- model-selectionSkill
- new-campaignSkill
- new-projectSkill
- record-decisionSkill
- reportSkill
- run-campaignSkill
- simulation-designSkill
- verifySkill
The file
We split this skill into the rules it gives an agent
1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 39
Do not reach for it when a single lever family is merely unfinished (keep mining), when the run crashed (debug), or when the question is …
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
assumption-audit — when optimization stalls, audit what it inherits
A plateau has two species and the standard response fixes only one. If the levers are exhausted,
escalate or pivot (docs/reference/pivoting.md). If instead the stall is caused by a wrong inherited
value (a miscalibration, a mis-derived quantity, or a misread classification that every experiment
carries), every lever sits downstream of the error and escalation spends budget re-measuring the same
wall. The rule this skill enforces: a hard plateau is evidence about the campaign's assumptions as well
as its levers. Before committing more optimization experiments, audit what the current best inherits,
and buy one experiment that re-measures the top suspect from scratch.
The failure has a characteristic shape. A classification or a calibration is adopted without being re-measured, a derived quantity is computed from it, and every downstream experiment inherits that quantity. The effect under study can still appear in the data and still pass the loop's own control experiments while one-lever optimization arms stay pinned at the same signal-to-noise floor, because each arm searches at the inherited value. A loop can design the correct discriminating measurement and still keep the wrong number, by framing that measurement as a confirmation of the incumbent and reading the mismatch as an artifact. No lever fixes a value that is never re-opened.
When to run it
Trigger on any of these, whichever comes first:
- Cross-family floor: one-lever experiments across ≥2 independent lever families land at the same
performance floor. "Same" means indistinguishable within the metric's replicate spread, the noise
floor
verify's campaign mode establishes. A floor shared across independent families is the signature of a binding constraint upstream of all of them. - A-priori gap: the observed performance sits orders of magnitude from its own a-priori/CRB-style expectation and no lever moves the gap.
- Unresponsive effect: an effect already reported as present whose strength shows no response beyond that replicate spread across the swept range of the levers that should modulate it.
- Scheduled:
campaign-statusdetects a plateau and lever coverage is already broad.
Do not reach for it when a single lever family is merely unfinished (keep mining), when the run crashed
(debug), or when the question is which lever to try next (pivoting.md). This skill asks a different
question: what does every experiment believe that nobody has re-measured?
Rule out the cheaper rival diagnosis first. The cross-family floor has a second explanation that does not involve a wrong inherited value: the space may be interaction-dominated, so that no lever moves the metric alone while a combination would. One-at-a-time search cannot escape such a space by construction, and it reads the same as an upstream constraint. Before auditing the inheritance, spend one small factorial or paired-lever run across the two families that floored. If the pair moves what neither lever moved, the plateau is an interaction rather than a bad assumption, and this skill is the wrong tool. That test is the cheaper one; running it second means re-measuring a calibration that was fine.
The method
- Enumerate the inheritance. List every value the current-best configuration carries that was not
measured in the current campaign phase: calibrations, derived quantities (anything computed from a
measurement plus an assumption), adopted constants, and classifications (a peak identification, a
mode assignment, a pattern read). Classifications are the entries most often omitted. A
classification is an assumption no less than a number is: count what is actually there before naming
what it is. Tag each entry with its provenance (the source-authority ladder: PINNED / REPORTED /
INFERRED / RECALLED / REASONED — see
record-decision). PINNED entries are near-immune; INFERRED and REASONED are the prime suspects. - Interrogate each against the stall signature. For each entry ask: if this were wrong, would the observed stall follow? A mechanism sketch is required. "Carrier wrong by a few kHz ⇒ real line present but outside the estimator window ⇒ per-experiment SNR pinned at noise floor while detection controls still pass" is a mechanism sketch; "maybe the calibration drifted" is not. Rank the entries by explanatory power × provenance weakness × cheapness of the discriminating test.
- Buy one discriminating experiment for the top suspect. Two clauses are binding.
- Solve, do not confirm. The experiment must estimate the suspect value from scratch and compare with the incumbent only afterwards. A consistency check framed as "verify the current value" invites reading any mismatch as an artifact, which is how a loop runs the right experiment and keeps the wrong number. Design the analysis so its output is a value, not a verdict on the incumbent.
- Operating-point validity. Enumerate everything else that changes between this experiment and the ones it will be compared against, and re-derive any calibration that is valid only at the operating point where it was taken: a pulse calibration at a new frequency or amplitude, a gain at a new range, a response at a new temperature. A discriminating test run with an out-of-point calibration can refute a true hypothesis cleanly. Pre-registered falsification combined with an unmodeled confound produces a confident wrong conclusion.
- Close the loop on the verdict.
- Suspect cleared: record it (
record-decision, with the discriminating evidence and a revisit-if trigger) so the audit never re-litigates it, then move to the next suspect or back to optimization. - Suspect falls: the revised value is an invalidation event, not a tweak. Re-baseline anything
that inherited it, mark affected findings for re-verification, and if standing results are
invalidated wholesale, use
fork-campaign. Then return to optimization mode. The audit is a mode change, not a new home.
- Suspect cleared: record it (
Rules of evidence
- "The levers aren't exhausted yet" does not defer the audit. One audit round costs one experiment; a wrong inherited value costs every experiment until it is found. When the cross-family-floor signature is present, the audit is the cheaper option.
- An assumption absent from the list is never audited. Enumerate classifications, sign conventions, and
analysis-chain constants alongside the obvious calibrations;
frame-problem's physics inventory is the seed. - A confirmation is not an estimate. Evidence that the data is consistent with the incumbent value at low signal-to-noise is weak by construction. Design the discriminating experiment so that a wrong incumbent produces a different number, not a slightly worse fit.
- Provenance does the ranking; mechanism does the vetting. Weak provenance nominates a suspect. Only a sketch of how its being wrong produces the observed stall keeps it on the list. Both are required.
- Record the cleared suspects. An audit that leaves no
record-decisiontrail is re-run from scratch at the next plateau, or skipped on the belief that it was already checked.
Output
A short audit record (journal or findings note): the inheritance table (value → provenance → stall
mechanism → rank), the discriminating experiment with its solve-don't-confirm design and operating-point
check, the verdict, and the record-decision entries for cleared suspects. If a value fell, record the
invalidation scope: what re-baselines and what re-verifies.
Composition
campaign-status triggers this at a resistant plateau (its §4 re-plan) · roles/worker.md's Getting
Unstuck block names the trigger conditions · frame-problem seeds the inheritance enumeration ·
record-decision stores provenance tags, cleared suspects, and revisit-if triggers ·
attribute-mechanism takes over when the audit surfaces a signature needing a cause ·
verify grades the discriminating experiment's result before the revised value is adopted ·
fork-campaign if a fallen assumption invalidates standing findings · docs/reference/pivoting.md
remains the sibling path for the other species of plateau (exhausted levers).
verify §5b is the prospective form of this discipline: falsify an INFERRED or
RECALLED fact before it becomes load-bearing. This skill is the retrospective audit for when that gate
was missed and a plateau is the symptom.
Checklist
- Trigger condition named (cross-family floor / a-priori gap / unresponsive effect / scheduled)?
- Inheritance enumerated in writing, including classifications and analysis constants?
- Every entry provenance-tagged (PINNED…REASONED)?
- Each suspect vetted with a stall mechanism sketch?
- Discriminating experiment solves for the value (output is a number, not a verdict)?
- Operating-point validity audited, every calibration valid where this test runs?
- Cleared suspects recorded with revisit-if triggers?
- Fallen value treated as an invalidation event (re-baseline / re-verify / fork if needed)?
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.

