freshness-contract
Skill15 starsChanged 15 days agoApache-2.0View on GitHub
Categorical decision table for reusing cached evidence — when an artifact you already read, a banked test result, a primer, a worker report, or a probe verdict is still trustworthy, and when it must be spot-checked or re-verified. Inputs are observable (artifact class, age anchors, intervening writes, named invalidators); output is reuse / spot-check / re-verify / accept-labeled-risk. Conservative by construction — unclassified artifacts and conflicting signals always take the more restrictive path; no invented TTLs. Trigger when the user runs /freshness-contract, asks "is this still current", "can I trust what I read earlier", "do I need to re-check this", or before reusing prior evidence for a decision after time, writes, or environment changes. Not /double-check (re-verifies one claim's content) or /verify (formal phase gate) — freshness-contract decides whether OLD evidence still counts before those tools decide what NEW evidence shows.
In this repository95 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- llms.txtllms.txt
- agent-mailboxSkill
- agent-outputSkill
- ask-gateSkill
- ask-meSkill
- audit-coupled-constantSkill
- budget-checkSkill
- build-prototypeSkill
- caller-optionsSkill
- cold-reviewSkill
- debug-taskSkill
- define-termsSkill
- defuddleSkill
- design-an-interfaceSkill
- diff-recapSkill
- directives-auditSkill
- domain-checkSkill
- double-checkSkill
- extract-signalSkill
- github-syncSkill
- handoff-executeSkill
- handoffSkill
- headless-claudeSkill
- headless-codexSkill
- headless-geminiSkill
- headless-grokSkill
- headless-modelsSkill
- headless-update-modelsSkill
- headless-usageSkill
- human-drawSkill
- human-mergeSkill
- human-outputSkill
- human-rewriteSkill
- implement-taskSkill
- improve-codebase-architectureSkill
- insight-adversarialSkill
- insight-anglesSkill
- insight-assessSkill
- insight-critiqueSkill
- insight-cross-examineSkill
- insight-exploreSkill
- insight-premortemSkill
- insight-reference-classSkill
- insight-retroSkill
- insight-root-causeSkill
- insight-skill-gapSkill
- insight-test-assumptionSkill
- insight-value-of-informationSkill
- investigateSkill
- json-canvasSkill
- map-checkSkill
- map-initSkill
- map-maintainSkill
- map-rulesSkill
- map-thisSkill
- monorepo-depsSkill
- multi-agent-modeSkill
- next-skillsSkill
- The first 60 shown.
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 70
No dedicated log stream, no cards, no sink — the record rides inside whatever report or decision consumed the evidence.
≈ “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
/freshness-contract
EXPERIMENTAL. A lookup, not a judgment ritual: it should cost LESS than the vibes it replaces. Fires only when prior evidence is about to be reused for a decision — never on every read, never as per-phase bookkeeping. It decides whether old proof still counts; what fresh proof must show belongs to your verification tools.
The design is deliberately isomorphic to HTTP caching (RFC 9111): explicit invalidation beats heuristics, conflicting signals resolve restrictively, and nothing is served stale silently. No TTL numbers ship in v1 — every "how old is too old" constant would be invented; the table routes by class and events, which are observable.
Step 1 — classify the artifact (volatility class)
| Class | Meaning | Examples |
| stable | exact version-pinned evidence, used for a question about that exact version — byte stability is not applicability: a superseded spec's old bytes still match while the governing version moved | a released spec consulted AS that release, a frozen/hash-pinned artifact, an archived record. Supersession or a dependency-version change is a named invalidator whenever the decision asks what is CURRENT |
| write-coupled | valid until someone writes to the source | a file you read this session, an index entry, a config, a map/roster document |
| env-coupled | valid until the environment shifts | a passing test that touches network/services/installed tools, a capability probe, a build result |
| clock-coupled | decays with time regardless of writes | anything embedding "current" state: prices, live statuses, date-dependent results |
| report | someone's account of state, not state itself | worker/subagent reports, peer summaries, self-reports of any kind |
Class is assigned per artifact kind at first encounter, not re-judged per use by whoever wants to skip a re-read.
Step 2 — check the observable signals
- Intervening writes — has the source (or its declared dependencies) changed since
as_of? (fingerprint, mtime, generation stamp, commit) - Named invalidators — did a declared invalidating event occur? (roster change, deploy, sync, schema bump, "re-prime after write")
- Decision leverage — is the reuse load-bearing for a decision, release, or Handler-facing claim, or merely orientation? Leverage is non-downgradable when the result supports a release, an irreversible or external action, a formal gate, or a Handler-facing recommendation — those are high, not judgment calls.
- Discriminator availability — does a cheap signal exist that is exclusive to the fresh state (a hash to recompute, a header to stat, a count to re-derive)?
Step 3 — the table (first match wins)
| Situation | Policy |
| Any named invalidator fired, or intervening write on a write-coupled source | re-verify |
| Conflicting or ambiguous signals, whatever the class | re-verify (restrictive conflict rule) |
| stable + fingerprint still matches | reuse |
| write-coupled + no intervening write + low/medium leverage | reuse |
| write-coupled + no intervening write + high leverage | spot-check the discriminator |
| env-coupled or clock-coupled + low/medium leverage | spot-check the discriminator |
| env-coupled or clock-coupled + high leverage | re-verify |
| report, any age, load-bearing | re-verify (a report is never promoted to state by aging) |
| report, orientation only | reuse, labeled as report |
| unclassified artifact kind (DEFAULT ROW) | spot-check; classify the kind before next reuse |
accept-labeled-risk is agent-electable ONLY on the no-cheap-discriminator row — it is never a bypass for a re-verify result elsewhere in the table. On any other row, proceeding despite a re-verify verdict requires explicit Handler authority (that is a Handler override, not a table output). Where it applies, it is never silent: the staleness risk is named next to the conclusion it feeds.
After the first matching policy is selected, handle discriminator availability for every spot-check result, including the default row: if no cheap exclusive discriminator exists, re-verify or explicitly accept labeled risk only where already permitted. Mandatory re-verification for invalidators, conflicts, high-leverage volatile evidence and load-bearing reports remains mandatory; this fallback never loosens those rows.
Output record (one line to a few lines, inline where the evidence is used)
freshness = { artifact, class, as_of, signals: {writes|invalidators|leverage},
decision: reuse|spot-check|re-verify|accept-labeled-risk,
discriminator_used?: <what was checked> }No dedicated log stream, no cards, no sink — the record rides inside whatever report or decision consumed the evidence.
Safety boundary
- Signals are observable properties of sources and events — never the agent's feeling of confidence about its memory.
- The table may be narrowed by a Handler's local policy (stricter rows); agents never loosen a row.
- TTLs, if ever added, must come from logged staleness observations, not authorship-day guesses; until then age alone never justifies reuse or refusal.
- Foreign freshness metadata (another party's "this is current" claim) is a report, not a signal — classify accordingly.
Self-improvement. On completion, run the Self-Improvement Protocol (
self-improve/SKILL.md): apply its signal taxonomy and threshold to this run; surface any surviving proposal for handler approval. Conservative — silent otherwise. Never auto-apply.
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.

