Optimistic Offline Lock Implementer

When to Use

This skill implements the Optimistic Offline Lock pattern after offline-concurrency-strategy-selector (or your team) has confirmed it is the right concurrency strategy. The pattern applies when a business transaction spans multiple HTTP requests — user loads a record, edits for seconds or minutes, then saves — and the collision frequency is low enough that detecting conflicts at commit time is acceptable.

Do not use if conflicts are frequent or rework cost is unacceptably high (use pessimistic locking instead). Do not use if the entire workflow fits in a single request/transaction (use database isolation levels).

Context & Input Gathering

Collect this before proceeding. Grep the codebase or ask the user directly.

Required:

1. Stack and ORM — Java/Hibernate, C#/EF Core, Python/SQLAlchemy, Ruby on Rails, Node.js/Knex, or hand-rolled SQL?
2. Entities needing protection — which tables/domain classes have concurrent-edit risk?
3. Schema mutability — can version columns be added, or is the schema frozen (legacy)?
4. Client round-trip — does a web/mobile client need to hold the version between GET and PUT/POST?
5. Unit of Work present? — is there an explicit UoW or does each repository method own its transaction?
6. Inconsistent read risk? — are there reads whose correctness the commit depends on (not just writes)?