PlaygroundCatalog › Database Schema Design
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.

▶ Run it free — no key needed 📝 Grade your existing draft View SKILL.md ↗

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