Skills directory
Architecture5-point gate · Node / API · Python · Any stack

The data model comes first

Schema before endpoints — constraints in the database, not in hope.

Use this when

Validation living only in the API layer

Tables without created_at

'We'll add the foreign key later'

The quality gate

  • Entities, relations, and ownership drawn before any endpoint exists
  • Invariants live in the schema: NOT NULL, unique, foreign keys, checks
  • Every table: created_at/updated_at; deletion strategy (hard/soft) decided explicitly
  • Migrations are reversible and rehearsed against production-shaped data
  • PII is inventoried: field, purpose, retention, deletion path

Prove it: Insert invalid data straight into the database — the schema itself must reject it.

Install or copy

Save the download as data-model-first/SKILL.md in your agent's supported skills directory, or copy the complete package below. Load it only when its description matches the work.

Portable SKILL.md
---
name: data-model-first
description: "Applies “The data model comes first” as a repeatable product-quality gate. Use during architecture work when schema before endpoints — constraints in the database, not in hope."
---

# The data model comes first

Apply this skill during **Architecture** work. It supports Node / API, Python, Any stack.

Schema before endpoints — constraints in the database, not in hope.

## Instructions

Design the data model before writing endpoints or UI: name the entities, their relations, and who owns each row. Enforce invariants in the schema itself — NOT NULL, unique, foreign keys, and check constraints are not optional garnish; app-level validation is a convenience layer, not the defense. Every table carries created_at/updated_at, and the deletion strategy (hard vs soft) is an explicit decision, not an accident. Write every migration with a tested rollback and rehearse against production-shaped data volumes. Maintain a PII inventory (field, purpose, retention, deletion path) and challenge every new personal field: do we truly need it?

## Detect the problem

- Validation living only in the API layer
- Tables without created_at
- 'We'll add the foreign key later'

## Hold the gate

Do not declare this phase complete until every item passes:

- [ ] Entities, relations, and ownership drawn before any endpoint exists
- [ ] Invariants live in the schema: NOT NULL, unique, foreign keys, checks
- [ ] Every table: created_at/updated_at; deletion strategy (hard/soft) decided explicitly
- [ ] Migrations are reversible and rehearsed against production-shaped data
- [ ] PII is inventoried: field, purpose, retention, deletion path

## Verify the result

Insert invalid data straight into the database — the schema itself must reject it.

More architecture skills

Want this quality gate applied to a real product decision?

Start a First Loop