agentleFS
Sign inStart free
shreyam1008shreyam1008/shre-skills/skills/caching/SKILL.md

caching

Skill0 starsChanged 48 days agoMITView on GitHub

Diagnoses stale data and defines HTTP/CDN caching, freshness, and invalidation policies. Use for cache headers, ETags, hashed assets, or cache-layer investigations. Service-worker lifecycle and TanStack APIs are separate workflows.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 2

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

    Prefer URL versioning (content hashes) so you never have to purge.

    line 52
  2. Very specific:

    Don't let a service worker pin stale HTML forever — version your SW caches and clean old ones on activate.

    line 54
  3. Distinctive:

    Always make a cached write path idempotent so retries don't double-apply.

    line 60

“Common” is measured: kept by at least 6 in 10 of the 11 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.

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

Caching

Caching is the highest-leverage performance lever and the easiest to get subtly wrong. Every caching decision reduces to one question:

Does the URL change when the content changes?

  • Yes (fingerprinted/hashed assets) → cache forever, immutable.
  • No (HTML docs, API responses) → short freshness + revalidation.

The layers (which may satisfy a request)

App/query cache → controlling Service Worker → browser HTTP cache → CDN → Origin

This is a conceptual model, not a guaranteed network path: a service worker can answer from Cache Storage or call fetch, which may use the HTTP cache. A hit can avoid downstream work entirely. Set policy deliberately at each layer.

HTTP Cache-Control — the essentials

  • max-age=<s> — browser freshness window.
  • s-maxage=<s> — freshness for shared caches (CDN); overrides max-age there. Lets you cache briefly in the browser but longer at the CDN.
  • public vs private — private = browser only (per-user data); public = shared caches may store it.
  • no-cache — store but revalidate before use (not "don't cache"). no-store — never store (truly sensitive/dynamic).
  • immutable — never revalidate during the freshness window; perfect for hashed assets.
  • stale-while-revalidate=<s> — serve stale instantly while refetching in the background (best of both for HTML/API).
  • must-revalidate — once stale, must check origin before reuse.
# Fingerprinted asset (app.9f3c2.js) — cache aggressively
Cache-Control: public, max-age=31536000, immutable

# Public, non-personalized HTML / API response allowing stale reuse
Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=600

Validation (revalidation without re-downloading)

  • ETag + If-None-Match, or Last-Modified + If-Modified-Since → origin returns 304 Not Modified (no body) when unchanged. Cheap freshness checks for HTML/API.

The golden pattern

  • Static assets: hash the filename at build time → max-age=31536000, immutable. New deploy = new URL = automatic cache bust.
  • HTML entry document: short/zero max-age + s-maxage + stale-while-revalidate, or revalidate via ETag — so users get new asset references promptly.
  • API responses: private for user data; short max-age/s-maxage + stale-while-revalidate for shared/list data; no-store for sensitive.

Invalidation (the hard part)

  • Prefer URL versioning (content hashes) so you never have to purge.
  • For unhashed resources, use CDN purge/tag-based invalidation on deploy/update.
  • Don't let a service worker pin stale HTML forever — version your SW caches and clean old ones on activate.

Application / data caches

  • TanStack Query, SWR, Apollo, RTK Query are in-memory caches keyed by query keys: tune staleTime/TTL, invalidate after mutations (see tanstack).
  • Server-side: memoize/single-flight expensive aggregates; add Redis/edge KV with explicit TTL + invalidation for hot reads.
  • Always make a cached write path idempotent so retries don't double-apply.

Service worker caches (precise control)

  • cache-first for hashed static assets, network-first for HTML/navigations, and SWR only for data that may safely be stale. Cache Storage does not enforce HTTP freshness or no-store: implement exclusions, expiry, and account/logout cleanup explicitly (see service-worker).

Debug checklist

  • Inspect response Cache-Control, ETag, Age, and CDN x-cache: HIT/MISS.
  • Stale content? Check every layer (browser, SW, CDN) — purge the right one.
  • "Update never shows" usually = HTML itself was cached too long, or SW serving stale HTML.

Reference

  • MDN: Cache-Control, Cache API, HTTP caching.
  • web.dev: "HTTP caching", "Love your cache".
  • Jono Alderson "A complete guide to HTTP caching"; your CDN's caching/purge docs.

Download now (ZIP)

  • Other versions13 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 13

    1. zebbern/claude-code-guide★ 4.7ksame name
    2. Resgrid/Core★ 229same name
    3. kid-sid/claude-spellbook★ 190same name
    4. proyecto26/system-design-skills★ 118same name
    5. nahid-sparktales/agent-dispatcher★ 59same name
    6. nimadorostkar/Claude-Skills-collection★ 33same name
    7. wpank/ai★ 11same name
    8. zdanovichnick/dotnet-pilot★ 5same name
    9. zebbern/termstack★ 4same name
    10. ffsshhttiikk/opencode-agents-skills★ 2same name

    3 more not listed

    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.

  • Used alongsideProjects with it also use background-jobs, resilience and 10 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • YepAPISkill

      background-jobs

      Queue workers with BullMQ/Inngest/Trigger.dev, job retries, dead letter queues, concurrency.

      Also in 4 projects that use this

    • MicrosoftSkill

      resilience

      Apply resilience patterns (retry, backoff, circuit breaking) when writing or reviewing code that makes outbound HTTP/REST calls, database operations, or any I/O that can experience transient failures. Use this skill when: (1) writing new code that calls external services or APIs, (2) reviewing code that uses fetch, HTTP clients, or service-to-service calls, (3) adding queue consumers or workers that interact with remote systems, (4) debugging intermittent failures in production.

      Also in 3 projects that use this

    • MicrosoftSkill

      authentication

      Wire this in whenever the app uses or connects to data — records, a database, entities, per-user data, row-level security — or when the user wants sign-in, accounts, login, or protected pages. Rayfin data is always accessed as an authenticated user, so **data implies auth**; only a static page over public data skips it. The starter ships as a no-auth "hello world" that previews with no backend, and the full Fabric auth scaffolding is already in the project — this skill wires it in: AuthProvider + bootstrapAuth in main.tsx, the route guard in App.tsx, the sign-in page, sign-out, and the env/deploy requirement. Triggers: auth, authentication, sign in, sign-in, login, log in, sign out, logout, account, user, identity, protect route, require login, gated page, data, database, records, per-user, row-level security, who is the current user, Fabric auth, Entra.

      Also in 4 projects that use this

    • harperaaSkill

      rate-limiting

      Implement rate limiting to prevent brute force attacks, spam, and resource abuse. Use this skill when you need to protect endpoints from automated attacks, prevent API abuse, limit request frequency, or control infrastructure costs. Triggers include "rate limiting", "rate limit", "brute force", "prevent spam", "API abuse", "resource exhaustion", "DoS", "withRateLimit", "too many requests", "429 error".

      Also in 3 projects that use this

    • SentrySkill

      feature-flags

      Gate a Sentry feature behind a FlagPole feature flag. Use when adding a feature flag, registering a flag in temporary.py, checking a flag from Python or the frontend, enabling a flag in tests, or asking where FlagPole rollout config lives. Trigger on "add a feature flag", "gate this behind a flag", "register a flag", "features.has", "api_expose", "OrganizationFeature", "ProjectFeature", "FlagPole".

      Also in 3 projects that use this

    • JohnJBorenSkill

      ci-cd

      CI/CD pipeline design, GitHub Actions, testing automation, and deployment strategies

      Also in 4 projects that use this

    • +1 more from microsoft
  • In this repository21 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.

Check your setup, free