Agent skill · software engineering · sickn33

frontend-optimistic-mutations

A portable, framework-agnostic discipline for the write path of any React or React Native app using a query/cache layer.

Why this skill is useful

Adds a framework-agnostic approach to optimistic updates in React applications, detailing specific lifecycle steps and cache management that the AI wouldn't reliably generate on its own.

What it needs

About 7k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.

What this skill does

Frontend Optimistic Mutations (the write path) When to Use Use this skill when you need a portable, framework-agnostic discipline for the write path of any React or React Native app using a query/cache layer. Codifies the optimistic-update lifecycle (cancel in-flight queries → snapshot every affected cache → patch instantly → roll back verbatim on error → invalidate on... Portable skill — readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and others. This skill describes the discipline of the write path — optimistic updates, rollback, idempotency, cache coherence — not a UI library or a styling system. It builds directly on the frontend-data-contracts skill (writes go through the typed client) and the frontend-architecture skill (mutations live in modules/{feature}/hooks/, keyed by a factory). The goal: a write feels instant (the UI reflects it before the server confirms), is safe (a failure restores the exact prior state, and a retry never double-charges), and leaves the cache coherent (the detail view and every list page agree). All three at once — that's the craft. --- 0. The five core ideas 1. The optimistic lifecycle is fixed. cancel → snapshot → patch → (error: roll back) → (settle: invalidate). Every optimistic mutation follows the same five beats. 2. Roll back verbatim. On failure, restore the exact snapshot taken before the patch — not a "best guess" re-derivation. Keep the snapshot in mutation context. 3. Idempotency is generated once, not per attempt. The key is created at form init (or first intent), so a network retry replays the original server response instead of performing the action twice. 4. Caches move in lock-step. A status change patches the detail cache and every list page that contains the entity, so badges never disagree across surfaces. 5. Server state never enters the client store. Optimistic state lives in the query cache, not Zustand/Redux. The cache is the single source of truth for server data (per frontend-architecture §4). …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills sickn33/frontend-optimistic-mutations--141f15

View the source on GitHub

Browse the @skills marketplace