Start a fresh conversation. Replace the highlighted placeholders.
Use database-design to propose a normalized schema, relationships, keys, and indexing strategy for [application requirements and query patterns], taking [database/ORM preferences and deployment environment] into account. Ask about unclear database preferences, then read only the relevant selection, schema, and indexing references. Explain context-based tradeoffs and likely N+1 risks. Return the proposal and validation plan without applying migrations or changing data. If using the schema helper, label it a read-only heuristic inventory and preserve incomplete/unsupported outcomes; use the project's ORM validator for actual syntax/type checks.
Required inputs
[application requirements and query patterns]
[database/ORM preferences and deployment environment]
User-approved starter prompt based on a pinned source version; check current skill requirements before running. Task evidence ↗
Read ONLY files relevant to the request! Check the content map, find what you need.
File
Description
When to Read
database-selection.md
PostgreSQL vs Neon vs Turso vs SQLite
Choosing database
orm-selection.md
Drizzle vs Prisma vs Kysely
Choosing ORM
schema-design.md
Normalization, PKs, relationships
Designing schema
indexing.md
Index types, composite indexes
Performance tuning
optimization.md
N+1, EXPLAIN ANALYZE
Query optimization
migrations.md
Safe migrations, serverless DBs
Schema changes
⚠️ Core Principle
ASK user for database preferences when unclear
Choose database/ORM based on CONTEXT
Don't default to PostgreSQL for everything
Decision Checklist
Before designing schema:
Asked user about database preference?
Chosen database for THIS context?
Considered deployment environment?
Planned index strategy?
Defined relationship types?
Anti-Patterns
❌ Default to PostgreSQL for simple apps (SQLite may suffice)
❌ Skip indexing
❌ Use SELECT * in production
❌ Store JSON when structured data is better
❌ Ignore N+1 queries
When to Use
Use when selecting a database model, reviewing schema relationships and indexes, or assessing a proposed schema with the bundled advisory tools.
Schema helper
scripts/schema_validator.py is a read-only heuristic inventory, not a Prisma or Drizzle parser. Missing schemas, unsupported formats and heuristic-only results return nonzero with passed: false and analysis_complete: false. Use the project-local ORM validator for syntax and type checks; review migration and constraint semantics separately.
Limitations
Use this skill only when the task clearly matches the scope described above.
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.