# Forge Cache

> First decide whether caching is justified, then audit keys, invalidation, consistency, privacy, and failure behavior.

- Skill: `is-bo/forge-cache-3` (Agent Skill)
- Install (CLI): `npx skillmds@latest add is-bo/forge-cache-3`
- Raw SKILL.md: https://api.skillmd.com/api/skills/is-bo/forge-cache-3/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: is-bo (https://skillmd.com/u/is-bo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/is-bo/forge-cache-3

---


# forge-cache: Caching

Engine: Hybrid — Forge + Vercel, Cloudflare

## Purpose

First decide whether caching is justified, then audit keys, invalidation, consistency, privacy, and failure behavior.


## Deterministic runtime composition

Before loading any provider procedure, run:

Resolve `../../runtime/cli/src/composition-entry.js` relative to this `SKILL.md`, then run:

`node "<resolved-absolute-runner-path>" cache compose --workflow audit --root "<repository-root>" --dry-run --json`

Add one repeatable `--request <provider-or-source>` flag for each explicit user request. Add
`--condition <task-condition>` or `--risk-surface <surface>` only for a task fact you directly
proved; never infer one from generic wording. The command above is the default for this
audit-oriented module; for implementation use `--workflow build`, and for a fix, retest, or
release gate use `--workflow fix`, `verify`, or `ship` respectively. Read the JSON response,
keep the Forge contract at index zero, and resolve paths against the absolute `runtime_root`
reported in that response. Read `eager[].runtimePath` when entering the module. The full
`selected[]` list is availability/provenance; load only `deferred[].runtimePath` when the task
reaches that concern, in tier order. Refuse any path that escapes the root. Respect every reported
suppression and context budget. If `missing` is non-empty, stop and report the installation as
damaged; do not improvise a prose fallback. The runner and specialist content may live in a plugin
cache or global installation; never assume they are inside the audited repository.


Resolve and read `../fullstack-forge/references/shared/module-contract.md` (applicability,
execution, mutation, verification, completion) and
`../fullstack-forge/references/shared/evidence-rules.md` (statuses, standards, tools, findings via
`../fullstack-forge/references/PROTOCOL.md`) relative to this module `SKILL.md` before reporting.

Never hide failed checks or claim that an operation ran when it did not.

## Automatic activation signals

Activate when a request or direct repository evidence involves caching, when
the user explicitly names `forge-cache`, or when discovery proves an applicable boundary.

- Detected caches, CDNs, memoization, or a measured proposal to add caching

## When not to activate

- No cache and no measured latency or load need

## Automated support

Relevant discovery inputs are:

- cache clients and configuration
- query and request flows
- performance evidence

Deterministic support, bounded evidence only:

- `inspect-cache-usage`

## Agent inspection procedure

1. First establish necessity: find the measured bottleneck a cache addresses; if none exists, conclude that no cache — including Redis — is justified.
2. Inventory cache layers (browser, CDN, application, framework) and every key-construction site.
3. Verify keys include every dimension that changes the value: user, tenant, locale, and version; test two-user and two-tenant collisions.
4. Trace invalidation for each write path that changes cached data, and check TTL, stampede protection, and negative caching.
5. Inspect failure behavior (cache down must degrade correctly), sensitive-data exposure in shared caches, and memory or eviction limits.

Manual inspection requirements:

- Review consistency tolerance with product owners
- Validate managed cache eviction and network policy

Stack-specific guidance:

- Account for framework, CDN, browser, server, and data caches as separate layers

## Evidence to collect

Standards used as criteria:

- Redis eviction documentation
- RFC 9111

## Common production failures

- Require a measured bottleneck and explicit freshness contract before recommending a cache
- Inspect key completeness, tenant and user scope, TTL, invalidation, stampede control, negative caching, serialization, and versioning
- Check sensitive-data exposure, authorization changes, eviction, memory limits, outage fallback, and observability

## Missing-control checks

Each item needs direct evidence or one reasoned status.

- Evidence that caching is justified
- Cache layers
- Browser caching
- CDN caching
- Server caching
- Framework caching
- Redis usage
- Cache keys
- Tenant isolation
- User isolation
- TTL
- Invalidation
- Stampede protection
- Stale-data tolerance
- Negative caching
- Cache size
- Serialization
- Failure fallback
- Sensitive data
- Cache poisoning
- Cross-user leakage
- Cross-tenant leakage
- Cache observability
- An explicit conclusion that Redis is unnecessary when evidence supports it

## Commands and tools

- Run `forge cache audit --json` or `fullstack-forge cache audit --json` when
  an explicit audit is requested and the CLI is installed. Normal feature work does not require it.

## Safe fixes

- Namespace incomplete keys and add bounded TTLs where semantics are established
- Add cache hit/miss and fallback telemetry without sensitive values

## Approval-required changes

- Introducing Redis or changing consistency and invalidation semantics

## Verification

- Exercise hit, miss, stale, invalidated, stampede, and cache-down paths
- Confirm cross-user and cross-tenant isolation

## Completion contract

Follow `fullstack-forge/references/shared/completion.md` and the limitations below.

## Known limitations

- Cache value requires workload measurements
- Cache-key resolution is bounded to local static expressions; cross-file helpers, dynamic computed properties, and non-linear reassignment remain NOT_VERIFIED