entity-model-auditor

Audits entity data models against PRDs and produces field-by-field migration reports.

Updated Jan 10, 2026
One-click install
npx skills add https://github.com/Rabbit-Ivan/Ivan-skills --skill entity-model-auditor-rabbit-ivan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: entity-model-auditor
Source: https://github.com/Rabbit-Ivan/Ivan-skills/tree/main/skills/entity-model-auditor
Command: npx skills add https://github.com/Rabbit-Ivan/Ivan-skills --skill entity-model-auditor-rabbit-ivan

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Deciding which fields an entity should have and where each field should live (table column, config blob, or runtime-computed) is error-prone, leading to bloated schemas, redundant fields, and painful migrations. This Skill turns a PRD plus an optional codebase into a structured audit that answers what should exist, what exists now, and what must change. ## Core Features & Use Cases - Five-Cut Field Classification: Every field passes through existence, store-vs-compute, column-vs-config, system-vs-content, and stored-form decisions, each framed as a cost-to-change judgment. - 8-Column Audit Table: Produces a target-vs-current comparison per entity covering type, classification, field nature, existence justification, current source, and required change. - Migration Change List: Groups renames, new fields, removals, moves, and API gaps into an actionable plan, plus design-decision justifications. - Use Case: Paste a PRD and a Prisma or SQLAlchemy model and ask whether the fields are right; receive a full audit report showing which columns to keep, which to move into a jsonb config blob, and which to compute at runtime. ## Quick Start Paste your PRD and current database model, then ask the agent to audit the entity fields and produce the data model audit report.

Frequently Asked Questions about entity-model-auditor

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a data model against a PRD?▼

Provide the PRD and optionally your codebase models, then extract every field per entity and classify each through five cuts: existence, store-vs-compute, column-vs-config, system-vs-content, and stored form. The result is an 8-column audit table plus a grouped change list.

When should a field be a table column versus a jsonb config blob?▼

Use a table column when you need to filter, sort, or query by the value; use a config blob for user-facing tuning knobs that never appear in queries. Config fields avoid a schema migration each time options change.

How do I decide whether to store a field or compute it at runtime?▼

Do not store values derivable from other persisted data, pure functions of other fields, or values that change automatically from system events. Document the derivation rule and compute them at API response or request execution time.

What is the difference between a system field and a content field?▼

A system field is one the backend branches on with if/switch logic, so it needs enum validation and a code change per new option. A content field flows into prompts or display without backend interpretation, so it stays free text updated via template data.

When should I not use a data model audit?▼

Skip the audit when the PRD itself is unsettled, since conflicting requirements must be fixed first, or when the dispute is purely about naming. It also does not replace general code-quality or component-design reviews.