agentleFS
allemaarallemaar/open-skills/skills/freshness-contract/SKILL.md

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.

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
  1. Distinctive:

    No dedicated log stream, no cards, no sink — the record rides inside whatever report or decision consumed the evidence.

    line 70

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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)

ClassMeaningExamples
stableexact 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 moveda 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-coupledvalid until someone writes to the sourcea file you read this session, an index entry, a config, a map/roster document
env-coupledvalid until the environment shiftsa passing test that touches network/services/installed tools, a capability probe, a build result
clock-coupleddecays with time regardless of writesanything embedding "current" state: prices, live statuses, date-dependent results
reportsomeone's account of state, not state itselfworker/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)

SituationPolicy
Any named invalidator fired, or intervening write on a write-coupled sourcere-verify
Conflicting or ambiguous signals, whatever the classre-verify (restrictive conflict rule)
stable + fingerprint still matchesreuse
write-coupled + no intervening write + low/medium leveragereuse
write-coupled + no intervening write + high leveragespot-check the discriminator
env-coupled or clock-coupled + low/medium leveragespot-check the discriminator
env-coupled or clock-coupled + high leveragere-verify
report, any age, load-bearingre-verify (a report is never promoted to state by aging)
report, orientation onlyreuse, 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.