reviewing-data-model

Installation
SKILL.md

reviewing-data-model — SKILL.md

Variant: standard · When to use: judging a finished data-model document as an acceptance gate — checking an engineer can build the schema and write correct queries from it, then emitting VERDICT: approve|revise with actionable findings. Greenfield, or an amend (delta-scoped).

Overview

This skill is the review half of a producing/judging data-model pair. Loaded by a reviewer who holds a finished data-model document — the persistence/domain model an engineer implements the schema from and everyone who queries the data reads — it judges that doc against one question: can an engineer create the schema and write correct queries from it, and are the model's integrity rules + tradeoffs explicit? It applies a fixed 9-condition integrity + queryability checklist — the same bar a data-model author produces to (authoring-data-model's ## Output), so the produce-bar and the review-bar do not drift — then emits a single machine-parseable verdict plus findings the author can act on in one revision pass. It is an acceptance gate — it does not author, fix, or rewrite the model; it judges and returns findings, and the producer revises.

The bar is single-sourced with the author. The author's techniques — the ER notation (Chen / crow's-foot / Mermaid), the conceptual/logical/physical level framing, the normal-form-derivation procedure — are aids the reviewer judges by OUTCOME (is every entity typed + keyed? does every relationship carry cardinality + a referential rule? does every index trace to an access pattern?), never conditions to demand. But note the boundary: the access-pattern-justified-index discipline (cond-3), referential integrity (cond-2), and the normalization + paradigm reasoning (cond-4) ARE real, load-bearing conditions for a data model — this IS the persistence design, so do NOT under-review them as "implementation detail." What stays an aid is the technique (a named notation/level/derivation), not the outcome (a typed entity, a justified index, a stated tradeoff).

Paradigm-aware (load-bearing). The model may be relational, document/NoSQL, graph, wide-column, or key-value. Judge each in its own idiom: a NoSQL/graph/wide-column model legitimately has no normal form and no FK (it uses embed-vs-reference / edges / a partition+clustering key). Demanding a relational idiom of a non-relational model is the cardinal relational-reflex false-revise — do not do it.

When to activate

  • A finished data-model doc needs an accept/revise decision before an engineer builds the schema.
  • You are the independent reviewer / gate for a data model a producer just authored.
  • Re-judging a revised data model after a prior revise verdict.
  • Reviewing an amend — an approved model + a change request — as a delta-scoped review (cond-9).
Installs
7
GitHub Stars
1
First Seen
4 days ago
reviewing-data-model — bm629/agent-skills