Sql Pro
Design normalized schemas, write correct SQL DDL/DML, and apply database patterns when bootstrapping or evolving a solo product's datastore.
Overview
Sql-pro is an agent skill most often used in Build (also Validate scope and Operate infra) that teaches relational database design and idiomatic SQL through normalization and constraint examples.
Install
npx skills add https://github.com/jeffallan/claude-skills --skill sql-proWhat is this skill?
- Normalization walkthroughs (1NF–3NF) with bad/good DDL contrasts
- Relational modeling patterns: orders, products, phones, and composite keys
- CHECK constraints, foreign keys, and snapshot fields for order-time pricing
- Practical PostgreSQL-style SERIAL/INT patterns for indie CRUD apps
- Foundation for queries, migrations, and performance work on real schemas
- Includes worked 1NF and 2NF examples with explicit bad vs good table definitions
Adoption & trust: 4k installs on skills.sh; 9.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps generating wide, denormalized tables or SQL that will break when orders, catalogs, or customer data grow.
Who is it for?
Indie SaaS, APIs, and ecommerce backends where Postgres or similar SQL is the system of record.
Skip if: Pure NoSQL document modeling, one-off analytics in warehouses only, or teams that need vendor-certified DBA runbooks.
When should I use this skill?
Designing or refactoring relational schemas, writing SQL DDL, or reviewing data models for a backend feature.
What do I get? / Deliverables
You leave with clearer entity relationships, constraint-backed DDL, and patterns you can turn into migrations and repository code.
- Normalized table definitions
- Constraint and FK recommendations
- Migration-ready DDL snippets
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → Backend because the skill's core artifact is schema design and SQL that backs application features. Backend subphase fits normalization, constraints, indexes, and query modeling that agents apply while implementing persistence layers.
Where it fits
Map MVP entities and relationships before committing to an ORM schema.
Generate normalized order and product tables with snapshot pricing.
Review agent-produced migrations for missing FKs or non-atomic columns.
Refactor a denormalized customers table into atomic phone rows.
How it compares
Use as a schema-design playbook inside the agent—not a hosted database or ORM replacement.
Common Questions / FAQ
Who is sql-pro for?
Solo builders and small teams using AI coding agents to design or refactor SQL databases for web apps and APIs.
When should I use sql-pro?
In Validate when scoping MVP entities; in Build when writing migrations and backend models; in Operate when fixing legacy tables or planning safer schema iterations.
Is sql-pro safe to install?
It is documentation-style SQL guidance without mandatory cloud keys—still review the Security Audits panel on this page before letting an agent run destructive DDL against production.
SKILL.md
READMESKILL.md - Sql Pro
# Database Design ## Normalization Levels ```sql -- 1NF: Atomic values, no repeating groups -- Bad: Non-atomic phone column CREATE TABLE customers_bad ( customer_id INT PRIMARY KEY, name VARCHAR(100), phones VARCHAR(500) -- "555-1234,555-5678,555-9012" ); -- Good: Atomic values CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, name VARCHAR(100) NOT NULL ); CREATE TABLE customer_phones ( phone_id SERIAL PRIMARY KEY, customer_id INT NOT NULL REFERENCES customers(customer_id), phone_number VARCHAR(20) NOT NULL, phone_type VARCHAR(20) CHECK (phone_type IN ('mobile', 'home', 'work')) ); -- 2NF: No partial dependencies (all non-key attributes depend on entire key) -- Bad: Partial dependency on composite key CREATE TABLE order_items_bad ( order_id INT, product_id INT, product_name VARCHAR(100), -- Depends only on product_id product_price DECIMAL(10,2), -- Depends only on product_id quantity INT, PRIMARY KEY (order_id, product_id) ); -- Good: Separate product attributes CREATE TABLE products ( product_id SERIAL PRIMARY KEY, product_name VARCHAR(100) NOT NULL, product_price DECIMAL(10,2) NOT NULL CHECK (product_price >= 0) ); CREATE TABLE order_items ( order_id INT, product_id INT, quantity INT NOT NULL CHECK (quantity > 0), unit_price DECIMAL(10,2) NOT NULL, -- Snapshot at order time PRIMARY KEY (order_id, product_id), FOREIGN KEY (order_id) REFERENCES orders(order_id), FOREIGN KEY (product_id) REFERENCES products(product_id) ); -- 3NF: No transitive dependencies -- Bad: City/State depends on ZIP CREATE TABLE addresses_bad ( address_id INT PRIMARY KEY, street VARCHAR(200), city VARCHAR(100), state VARCHAR(2), zip_code VARCHAR(10) ); -- Good: Separate ZIP code reference CREATE TABLE zip_codes ( zip_code VARCHAR(10) PRIMARY KEY, city VARCHAR(100) NOT NULL, state VARCHAR(2) NOT NULL, county VARCHAR(100) ); CREATE TABLE addresses ( address_id SERIAL PRIMARY KEY, street VARCHAR(200) NOT NULL, zip_code VARCHAR(10) NOT NULL REFERENCES zip_codes(zip_code) ); ``` ## Primary and Foreign Keys ```sql -- Natural vs Surrogate keys -- Natural key (business meaning) CREATE TABLE countries ( country_code CHAR(2) PRIMARY KEY, -- ISO 3166-1 alpha-2 country_name VARCHAR(100) NOT NULL ); -- Surrogate key (technical, no business meaning) CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, -- Auto-incrementing surrogate email VARCHAR(255) NOT NULL UNIQUE, -- Natural candidate key name VARCHAR(100) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Composite primary key CREATE TABLE student_courses ( student_id INT, course_id INT, enrollment_date DATE NOT NULL, grade CHAR(2), PRIMARY KEY (student_id, course_id), FOREIGN KEY (student_id) REFERENCES students(student_id), FOREIGN KEY (course_id) REFERENCES courses(course_id) ); -- UUID primary keys (distributed systems, no sequence conflicts) CREATE TABLE events ( event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), event_type VARCHAR(50) NOT NULL, event_data JSONB, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Foreign key with cascading actions CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INT NOT NULL, order_date DATE DEFAULT CURRENT_DATE, FOREIGN KEY (customer_id) REFERENCES customers(customer_id) ON DELETE CASCADE -- Delete orders when customer deleted ON UPDATE CASCADE -- Update order.customer_id when customers.customer_id changes ); CREATE TABLE order_items ( order_item_id SERIAL PRIMARY KEY, order_id INT NOT NULL, product_id INT NOT NULL, quantity INT NOT NULL, FOREIGN KEY (order_id) REFERENCES orders(order_id) ON DELETE CASCADE, -- Delete items when order deleted FOREIGN KEY (product_id) REFERENCES products(product_id) ON DELETE RESTRICT -- Preve