/claude-db:explain

Plain-language description of a schema (or one finding), plus a paradigm-aware diagram. Read-only — explains, never edits or migrates.

$ARGUMENTS = <path|table|finding-id> [flags]. The target can be a schema/ORM/migration path, a single table/collection name, or a finding id from a prior audit.

What to do

Detect the paradigm/engine (scripts/detect-stack.mjs) and parse the model (scripts/parse-schema.mjs / parse-orm-python.py).
Give a plain-language description first — no jargon in the opening: what each entity holds, who owns what, and how the pieces connect, in the user's words ("a user has many orders; each order belongs to exactly one user").
Render a paradigm-aware diagram (Mermaid) with node scripts/gen-diagram.mjs --file <schema> [--paradigm relational|document|key-value|wide-column|graph] — paradigm-aware: ERD for relational, access-pattern map for document, key+GSI sketch for DynamoDB/KV, node/edge for graph:
- Relational → erDiagram with tables, PKs/FKs, and cardinality.
- Document → embedding/reference tree showing what is nested vs referenced.
- Key-value → access-pattern / key-design sketch (partition + sort key).
- Wide-column → table-per-query / partition-key layout.
- Vector → collection + metric/dimension + metadata filter fields.
- Time-series → hypertable / measurement + tags + retention.
- Graph → node-and-edge sketch with relationship types.
Offer an expandable technical layer below the plain description: exact column types, index definitions, constraint names, on-delete behavior — for the reader who wants the precise DDL.
If the target is a finding id, explain what it checks, which score/axis it affects (design | performance | both), why it matters, and how to reproduce it (verification.reproduce).