Backend · inspect by default

/backend-concurrency

Investigate races, locking, and competing updates

Use for violated invariants under competing operations; backend-idempotency handles repeat identity.

Make it your own.

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

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

Example · inspect
/just-vibe:backend-concurrency Investigate two concurrent reservations exceeding inventory capacity.
edge · apply
/just-vibe:backend-concurrency Prevent two concurrent reservations from selling the final available seat twice.
blocked · inspect
/just-vibe:backend-concurrency Review concurrency logic without performing live contention experiments.

What the agent does

  1. Write the shared invariant and the read/decide/write interleaving that violates it. Identify every worker/process and the actual shared boundary; list durable writes, external effects and cancellation points separately.
  2. Choose the narrowest supported atomicity mechanism for that boundary: a conditional write, transaction, version check or shared lock. Define who starts and ends the transaction or lease; never accidentally commit or roll back a caller-owned transaction.
  3. Validate before irreversible work and keep related invariant checks inside the serialization boundary when their inputs can race. Handle lock acquisition failure, deadlock/serialization conflict and cancellation with bounded retries only when replay is safe.
  4. Force contention using separate real connections or workers and deterministic coordination. Exercise success, rejection, interruption after partial work and cleanup; assert final state and number of effects, not just the number of returned responses.

Inputs

  • race symptom, shared resources, transaction semantics, and concurrency evidence.

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

Scope

Reads
Competing updates, locks, isolation, and atomicity.
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
Inspect for diagnosis; apply for an explicit fix to the violated invariant. Requires race symptom, shared resources, transaction semantics, and concurrency evidence.
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

  • Violating interleaving, invariant and ownership boundary, selected mechanism, retry/cleanup behavior, contention and interruption results.

How the work is checked

  • Independent workers preserve the invariant under contention. Failed operations leave owned resources usable, preserve caller-owned work, and cannot return success for an uncommitted or duplicated effect.

When to stop or clarify

  • No live contention experiments implicitly. Do not solve local races with process-local locks when multiple processes share the resource.

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
Write the invariant and a concrete violating interleaving; inspect isolation, lock order and actual worker topology.
Method
Choose supported conditional updates, version checks or transactions at the shared state boundary; retry whole units only when safe.
Pitfall
A process mutex does not protect multiple servers, and a pre-transaction balance read can become stale.
Check
Coordinate separate workers/connections at the contested read and verify one valid outcome, bounded retry and rollback after injected failure.

Situational decisions

When a caller already owns a transaction: Follow the API contract: participate with documented savepoint semantics or reject before touching it. Do not use unconditional commit/rollback cleanup that can consume unrelated work.

When multiple processes share the resource: A process-local mutex cannot establish the shared invariant. Verify at the storage or service boundary used by all writers.

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