rerun-before-verdict
Skill27 starsChanged 19 days agoApache-2.0View on GitHub
No verdict from a single uncontrolled run. A fix is proven by re-running the case that failed; a component's deadness or value is proven by a with/without comparison on the current system; a surprisingly good result stays a candidate until three consistent datapoints or a controlled before/after diff back it. Triggers when about to declare a fix proven, code dead, a component worthless, an approach impossible, or a result a breakthrough. Does not fire on interpreting a single success signal (verify-the-effect), on check integrity (prove-it-can-fail), or on the epistemic status of second-hand claims (findings-are-evidence).
In this repository56 other files it gives its agents.
- ai-surface-disciplineSkill
- blast-radius-grepSkill
- checkpoint-logSkill
- commission-the-rosterSkill
- committee-reviewSkill
- confirm-before-pushSkill
- constant-time-secret-compareSkill
- context-economySkill
- contract-reviewSkill
- cross-agent-reviewSkill
- date-parse-utc-safeSkill
- db-migration-verificationSkill
- deliverable-integritySkill
- dependency-upgrade-verificationSkill
- earn-every-lineSkill
- email-delivery-verificationSkill
- enforce-invariants-in-buildSkill
- env-change-verificationSkill
- findings-are-evidenceSkill
- fixtures-from-realitySkill
- flag-deferred-itemsSkill
- guard-the-spend-pathsSkill
- handoverSkill
- honest-failure-surfacingSkill
- legal-citation-integritySkill
- legal-notice-handlingSkill
- live-data-surgerySkill
- live-state-firstSkill
- lock-at-the-chokepointSkill
- mass-red-triageSkill
- measure-per-routeSkill
- no-silent-data-dropSkill
- one-real-rideSkill
- outbound-side-effect-idempotencySkill
- parallel-work-reconSkill
- pin-to-what-was-seenSkill
- plan-firstSkill
- price-the-spendSkill
- prove-it-can-failSkill
- reproduce-the-real-buildSkill
- safe-smokesSkill
- secrets-in-outputSkill
- server-side-authoritySkill
- skill-library-builderSkill
- spawn-from-declared-stateSkill
- statute-to-obligations-registerSkill
- substantiate-outward-claimsSkill
- team-loopSkill
- tool-layer-bytesSkill
- trace-one-recordSkill
- unordered-eventsSkill
- unslop-codeSkill
- unslop-textSkill
- unslop-uiSkill
- verified-citationsSkill
- verify-the-effectSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
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 24
Deadness and value are with/without questions: Run the current system with and without the component before declaring it dead, redundant, …
≈ “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
Rerun before verdict
A single run tells you where to look, never what is true. This skill governs the moment an observation is about to become a verdict — fixed, dead, worthless, impossible, breakthrough — and requires the controlled re-run that separates the two. Layer: leaf. Admitted by review rather than by the misses log — see Provenance — so candidate-tier until fires accumulate.
The rule
Observations are diagnostic-grade; verdicts need a re-run that isolates the claim. Good news gets the same discipline as bad.
How to apply
- A fix is proven by re-running the case that failed, not by the edit looking right. Diagnose, fix, re-run is one loop; acting on the diagnosis alone ships the theory, not the fix.
- Deadness and value are with/without questions. Run the current system with and without the component before declaring it dead, redundant, or worthless. Apparently dead code can be load-bearing, and an apparent inefficiency can be the price of a correct result — removal on inspection alone is how both get discovered in production.
- A suspiciously good result is a bug until ruled out. Assume measurement error, data leakage, or coincidence first. A finding stays a candidate until at least three consistent datapoints, or one controlled before/after comparison, back it. Celebrating first and checking second is the expensive order.
- "Impossible" is a verdict too. It earns one only after the plausible alternatives have been enumerated and actually tried, not after one failed attempt.
What this skill does not do
It does not interpret individual success signals — verify-the-effect owns proxy-vs-effect for a single operation. It does not judge whether a check is capable of failing (prove-it-can-fail), does not govern claims that arrive from agents or reviewers (findings-are-evidence governs those; this skill governs the run-count behind your own verdict), and does not gate "done" on shipped changes (one-real-ride).
Why
The single-run verdict is the cheapest place for a wrong conclusion to enter the record: once "fixed", "dead", or "10x faster" is written down, everything downstream inherits it without re-checking, and the with/without or before/after evidence that would have caught it becomes progressively more expensive to reconstruct.
Provenance
Distilled from two methodology kernels ("implausibly good is probably broken", "observations are not prescriptions") in Project Architect 2.0 (source-available; reviewed 2026-08-03). The other two kernels reviewed that day were already owned by findings-are-evidence, verify-the-effect, and prove-it-can-fail, and were not duplicated. Text written in-house; no upstream text copied.
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.