/backend-cache

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select backend-cache from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv backend-cache, /just-vibe backend-cache and /jv:backend-cache in Claude. See shortcut setup and context examples.

What the agent does

1. Map the source of truth, consumers, authorization scope and every invalidation path. Define the key as an unambiguous identity tuple including relevant tenant, user, filters and representation version; distinguish a cached empty/falsey value from a miss.
2. Specify separate absent, in-flight, successful and failed states. Define whether concurrent callers share work, when the freshness clock starts, the exact expiry boundary and zero-TTL behavior. Choose these from product requirements, not a convenient implementation default.
3. If asynchronous work is shared, assign cancellation ownership: a caller may stop waiting without cancelling shared work needed by other callers. Handle already-aborted callers, synchronous fetch errors, asynchronous rejection and listener cleanup on every terminal path.
4. If invalidation can race with an asynchronous fill, associate each fill with its current entry or generation. Invalidation must detach obsolete work so its late success or failure cannot overwrite or remove a newer entry. Decide explicitly whether existing waiters still receive the detached result.
5. Verify identity isolation, falsey hits, coalescing, expiry, failure/retry, per-caller cancellation and reversed completion after invalidation using a controlled clock and deferred work. Measure hit rate or latency only with an actual representative workload.

Inputs

• cached data, freshness tolerance, identity scope, workload, and failure expectations.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Key design, invalidation, expiry, stampedes, and fallback; implementation on request.

Writes

Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.

Mode

Plan caching behavior when requested; apply for requested implementation using resolved freshness, identity and failure semantics.

Prerequisites

Service source, data/interface contracts, framework/runtime versions, and test environment. Default apply operations target local code and isolated tests; live infrastructure/data mutations require their own requested scope.

Expected output

• Key and state/lifetime contract, chosen invalidation and cancellation ownership, implementation when requested, and independent isolation/race/failure evidence.

How the work is checked

• A cancelled or obsolete caller cannot poison another consumer or a newer fill; failures are recoverable according to the stated cache policy. Key collisions and valid falsey values do not cause cross-identity reuse or extra fetches.

When to stop or clarify

• Do not treat caching as a fix for incorrect queries. No production flush or shared-cache changes without explicit scope.

Handling missing context

Infer

Trace service callers, request contracts, authorization, transactions, retries and existing test infrastructure.

Assume

Use the existing persistence and framework; isolate local tests from live services.

Ask

Resolve ambiguous durability, duplication or consistency requirements before encoding them; absent production access does not prevent local implementation.

Technical guidance

Evidence

Inspect key dimensions, tenant scope, validity, empty-value handling, source failures and shared-fill ownership.

Method

Use identity-aware keys and generation checks on replacement/deletion; separate a waiter's cancellation from shared fill lifetime.

Pitfall

Old completion can resurrect invalidated data; treating zero or an empty list as a miss changes semantics.

Check

Test cross-tenant keys, zero TTL, empty values, invalidate-during-fill, late rejection and one canceled waiter with another still active.

Situational decisions

When an authorization change can outlive a cached response: Invalidate or version the relevant identity boundary; a long TTL cannot substitute for access control.

When multiple consumers share an in-flight fill: Separate waiter lifetimes from fill ownership. Test cancelling one waiter while another completes, and an old rejection arriving during a newer fill.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring