Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
oakoss avatar

Local First

  • 110 installs
  • 14 repo stars
  • Updated March 2, 2026
  • oakoss/agent-skills

Helps with ai & agent building tasks during AI-assisted development.

About

local-first is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.

  • local-first
  • AI & Agent Building
  • AI-coding skill

Local First by the numbers

  • 110 all-time installs (skills.sh)
  • +3 installs in the week ending Aug 4, 2026 (Skillselion tracking)
  • Ranked #4,040 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
  • Data as of Aug 4, 2026 (Skillselion catalog sync)
npx skills add https://github.com/oakoss/agent-skills --skill local-first

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs110
repo stars14
Last updatedMarch 2, 2026
Repositoryoakoss/agent-skills

What it does

Helps with ai & agent building tasks during AI-assisted development.

Files

SKILL.mdMarkdownGitHub ↗

Local-First

Overview

Local-first is an architecture where the application reads and writes to a local database, with changes syncing to the server in the background. The local database is the source of truth for the UI, providing instant reads, offline support, and optimistic writes by default.

When to use: Collaborative apps needing offline support, latency-sensitive UIs where instant response matters, apps with unreliable network conditions, real-time multiplayer features, mobile apps with intermittent connectivity.

When NOT to use: Simple CRUD apps with reliable connectivity, server-authoritative workflows (payments, inventory), content-heavy sites with minimal interactivity, apps where data freshness from the server is critical on every render.

Quick Reference

DecisionOptionsKey Consideration
Architecture modelServer-based, local-first, hybridOffline needs and latency tolerance drive the choice
Read pathServer fetch, local DB read, cache-then-networkLocal reads are instant; server reads block on network
Write pathServer mutation, optimistic update, local-first writeLocal writes never fail; sync handles delivery
Sync engineElectric, Zero, PowerSync, Replicache, LiveStorePostgres integration vs framework-agnostic
Client storageIndexedDB, OPFS, SQLite WASM, PGliteCapacity limits, query capability, browser support
Conflict resolutionLWW, CRDTs, server-wins, field-level mergeComplexity vs correctness tradeoff
Data modelNormalized tables, document store, CRDT documentsQuery patterns determine the best model
Partial replicationShapes, subscriptions, query-based syncSync only what the client needs
Progressive enhancementServer-first with local cache, full local-firstStart simple, add local-first incrementally
CQRS separationSeparate read/write models, unified modelLocal-first naturally separates reads from writes
Initial syncFull snapshot, incremental, progressive loadingFirst-load performance vs completeness
Auth integrationToken-based shape filtering, row-level securitySecurity lives at the sync layer, not the client
Schema evolutionAdditive migrations, versioned shapesLocal DB schema must evolve without data loss
State managementReplace React Query, coexist, hybrid approachLocal-first can replace or complement server state
Testing strategyMock sync engine, test offline scenarios, seed local DBTest both online and offline code paths

Common Mistakes

MistakeCorrect Approach
Going local-first for simple CRUD appsUse server-based architecture unless offline/latency is a real need
Choosing a sync engine before defining data modelDefine read/write patterns first, then pick the engine that fits
Ignoring conflict resolution until lateDesign conflict strategy alongside data model from the start
Syncing entire database to every clientUse partial replication (shapes, subscriptions) for relevant data
Treating local DB as a cacheLocal DB is the source of truth for the UI, not a cache layer
Using CRDTs for everythingLWW or server-wins is simpler and sufficient for most fields
Skipping progressive enhancementStart server-first, add local-first for high-value interactions
Not planning schema migrationsLocal databases need migration strategies just like server DBs

Delegation

If the electricsql skill is available, delegate ElectricSQL setup, shapes, auth, and write patterns to it.
Otherwise, recommend: pnpm dlx skills add oakoss/agent-skills -s electricsql -a claude-code -y
If the realtime-sync skill is available, delegate WebTransport, pub/sub, and CRDT implementation details to it.
If the tanstack-db skill is available, delegate collection setup, live queries, and optimistic mutation patterns to it.
Otherwise, recommend: pnpm dlx skills add oakoss/agent-skills -s tanstack-db -a claude-code -y
If the tanstack-start skill is available, delegate server function proxies and SSR integration to it.
Otherwise, recommend: pnpm dlx skills add oakoss/agent-skills -s tanstack-start -a claude-code -y
  • Architecture review: Use Plan agent to evaluate local-first vs server-based tradeoffs
  • Sync engine comparison: Use Explore agent to research current engine capabilities
  • Storage benchmarking: Use Task agent to test storage options for specific data patterns

References

  • Architecture patterns and decision framework
  • Sync engine comparison and selection guide
  • Client-side storage options and limits
  • Conflict resolution strategies
  • Offline resilience patterns
  • Schema versioning and migration
  • Multi-tenant data governance patterns
  • Testing strategies for local-first apps
  • End-to-end encryption for synced data
  • DevTools and debugging utilities
  • Server-first to local-first migration guide

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.