/db-integrity

Make it your own.

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

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

What the agent does

1. Translate each explicit business invariant into its row, relationship and transaction boundary. Distinguish nullability and historical exceptions from actual corruption; ambiguous policy remains a question, not a deletion rule.
2. Choose bounded counts and redacted examples against an identified snapshot. Assess scan/lock impact before live queries; use supplied artifacts when they are sufficient and do not infer current production state from stale samples.
3. For prevention, propose input validation separately from shared storage constraints and atomic multi-row checks. Cover type/range, ownership, uniqueness, referential rules and overflow where relevant to the invariant.
4. Propose repair with a selection predicate, expected count, restart behavior and recovery boundary; db-migrate or data-backfill applies an accepted change. Detection does not authorize a live cleanup or schema change.

Inputs

• invariants, schema, data scope, and bounded read permission.

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

Scope

Reads

Orphans, duplicates, invalid relationships, and constraint gaps; no automatic deletion or repair.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. db-migrate applies an accepted constraint and data-backfill runs a bounded repair.

Mode

Inspect; invariants, schema, data scope, and bounded read permission.

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

• Invariant and snapshot, bounded check/count/example evidence, prevention or scoped repair proposal, and uncertainty from missing policy or live data.

How the work is checked

• Checks detect an actual violating example and accept legitimate null/historical cases. Proposed preventive changes cannot leave partial multi-row state on interruption; repair claims name the snapshot and rows actually verified.

When to stop or clarify

• Ambiguous business rules prevent destructive recommendations. Large scans need a budget and appropriate execution environment.

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

Identify claimed invariants, enforcing constraints, existing violation counts and repair ownership.

Method

Use bounded aggregate queries and redacted synthetic examples; separate diagnosis, business reconciliation and constraint rollout.

Pitfall

Automatically deleting orphans can erase legitimate records awaiting asynchronous completion.

Check

Verify each invariant with both valid and invalid fixtures and show unresolved real-data policy decisions before any live repair.

Situational decisions

When data violates an ambiguous business rule: Report the evidence and policy question before proposing deletion or repair.

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