just-vibeDatabases · plan by default
/db-schema
Design or review tables, relationships, constraints, and types
Use for relational modeling and constraints; db-migrate plans transition of existing data.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select db-schema from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv db-schema, /just-vibe db-schema and /jv:db-schema in Claude. See shortcut setup and context examples.
/just-vibe:db-schema Design invoice relationships and deletion behavior against our actual database engine./just-vibe:db-schema Model optional memberships that cannot reference another tenant's organization./just-vibe:db-schema Design from requirements without a live database or inventing business cardinality.What the agent does
- Derive keys, ownership, cardinality and deletion rules from explicit invariants, and encode the enforceable ones.
- Check null semantics, uniqueness and access paths for the selected engine, and plan compatibility with existing data.
Inputs
- entities, invariants, access patterns, engine, and existing schema.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Tables, relationships, types, constraints, and lifecycle; no live DDL by default.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. db-migrate applies an accepted schema change.
- Mode
- Plan; entities, invariants, access patterns, engine, and existing schema.
- 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
- Entity/key/constraint table with rationale, deletion semantics, valid/invalid row examples, representative queries and migration considerations.
How the work is checked
- Invalid relationships are constrained; expected deletion behavior does not orphan required data.
When to stop or clarify
- Do not invent business cardinality or assume another database's semantics. Data ambiguities become explicit decisions.
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
- Derive cardinalities, ownership, nullability, units, natural/technical keys and deletion rules from requirements.
- Method
- Encode durable invariants with supported constraints and types; model money/time precision and tenant-aware uniqueness deliberately.
- Pitfall
- Application-only uniqueness races under concurrency; nullable columns can alter uniqueness semantics by engine/version.
- Check
- Test boundary values, duplicate keys, orphan writes and delete behavior on the target engine in an isolated database.
Situational decisions
When an optional relationship must still be tenant-consistent: Consider composite ownership constraints or equivalent enforceable checks rather than trusting a single foreign key.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.