/db-locks

Make it your own.

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

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

What the agent does

1. Correlate wait and blocker snapshots with transaction age, query identity and application transaction boundaries.
2. Follow the root blocker rather than the noisiest victim, distinguish transient waits from persistent contention, and propose targeted remedies.

Inputs

• engine, time window, affected workload, and lock/session metadata.

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

Scope

Reads

Blocking chains, deadlocks, transaction duration, and contention causes.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. fix applies an accepted code repair; operational changes need their own exact request.

Mode

Inspect; engine, time window, affected workload, and lock/session metadata.

Prerequisites

Actual engine/version, schema/migrations, query workload, and explicitly identified environment. Prefer supplied plans, metadata, and isolated fixtures. Even a SELECT can lock, call mutating functions, or overload a database; inspect semantics before execution. Executing an analyzed query is distinct from reading its plan.

Expected output

• Blocking chain or timeline with snapshot time, transaction boundary, likely cause and safe operational or code remedies.

How the work is checked

• The root blocker is distinguished from downstream victims; a completed deadlock is not confused with current blocking.

When to stop or clarify

• No session termination, transaction cancellation, or timeout changes implicitly. Redact sensitive query parameters and acknowledge snapshot limitations.

Handling missing context

Infer

Read engine/version, ORM/runner, schema and migration history from project artifacts before choosing SQL.

Assume

Prepare local SQL and isolated fixtures without assuming production size, locks or recovery guarantees.

Ask

Ask for environment, downtime or recovery constraints before live/destructive execution when missing; unavailable production access does not block migration files.

Technical guidance

Evidence

Inspect blocking chain, lock modes, transaction age, statements and isolation on the exact database.

Method

Find the root blocker and conflicting access order; consider shorter transactions, consistent ordering or bounded retries against the invariant.

Pitfall

The busiest blocked query may be a victim; terminating a session is an operational mutation with rollback consequences.

Check

Reproduce the interleaving with separate isolated connections and verify bounded recovery, not merely lower observed lock counts.

Situational decisions

When the reported deadlock already resolved: Separate historical deadlock analysis from current blocking and avoid terminating unrelated live sessions.

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