DS
Database Schema Design
🔵 Stable🕐 updated 2026-06-08
🔷 SkillSpec L3
pm-engineering
Document or design a database schema with entity relationships, table definitions, constraints, indexes, and access patterns. Use when asked to design a database, document an existing schema, model entities and relationships, define table structures, plan an index strategy, or produce a data model for review. Produces a structured schema document covering an ER diagram, table DDL definitions, index strategy, access pattern analysis, normalization decisions, and migration notes.
What to give it
▸Domain description — what the system does; what business objects are being modelled
▸Entities and relationships — the main things in the domain and how they relate (e.g. "a User has many Orders; an Order has many OrderItems; an OrderItem references a Product")
▸Expected query patterns — the most important read and write queries (e.g. "fetch all orders for a user, sorted by date"; "look up a product by SKU")
▸Database engine — PostgreSQL, MySQL, SQLite, CockroachDB, etc. — this affects DDL syntax and available types
▸Expected data volume — approximate row counts, growth rate, and any partitioning needs
▸Constraints — any existing conventions, naming standards, or migration constraints to respect
✅ The bar it holds itself to
Every skill in this library self-verifies — these are this skill's own quality checks, straight from its definition.
✓Every table has a primary key and a `created_at` column — no implicit ordering by row insertion
✓Every foreign key has a corresponding index — no missing FK indexes that would cause full table scans on joins
✓All TIMESTAMPTZ columns, not TIMESTAMP — timezone awareness is explicit
✓Soft-delete tables document the convention and where the filter is enforced (ORM scope, view, or query standard)
✓Every access pattern in the design has a supporting index or an explicit note that a full table scan is acceptable
✓JSONB columns are justified — not used as a substitute for proper schema design on queryable fields
✓Normalization decisions are documented with reasoning, not just stated
✓Migration notes address existing data if this is a schema change, not a greenfield schema
⚠️ What it refuses to do
Do not use JSONB columns as a substitute for proper relational schema design on fields that will be queried
Do not add indexes speculatively — every index must be justified by a specific access pattern
Do not omit timezone-awareness — use TIMESTAMPTZ, never plain TIMESTAMP
Do not design without documenting normalization decisions — future maintainers need the reasoning, not just the structure
Do not skip the access patterns section — schema without query patterns cannot be evaluated for correctness
Install
npx pm-claude-skills add --agent claude # or codex · cursor · gemini · hermes
# or one-line MCP (every skill, any client):
claude mcp add pm-skills -- npx -y pm-claude-skills-mcp
Start with
Related skills
🔌 Embed this skill
Drop this on your blog, docs, or site — it renders a "Run this skill" card:
<div data-pm-skill="database-schema-design"></div>
<script src="https://mohitagw15856.github.io/pm-claude-skills/embed.js" async></script>
💬 Discussion
Database Schema Design is one of 1078 open-source professional AI agent skills — all SkillSpec L3.
Try them all in the browser · ⭐ Star on GitHub · Browse the full catalog