Prisma Migration Skill
Critical Rules
- •NEVER edit files in
/apps/agent-api/prisma/migrations/directly - This is a "do not touch" zone per CLAUDE.md - •Always use Prisma CLI commands for migrations
- •Run typecheck after migrations to ensure Prisma client types are updated
Before Any Schema Change
- •Check the current schema at
/apps/agent-api/prisma/schema.prisma - •Review existing models and relationships
- •Plan changes carefully - migrations are permanent
Migration Workflow
Development Migration
bash
# Generate migration and apply to dev database pnpm --filter apps-agent-api prisma migrate dev --name <descriptive-name> # Regenerate Prisma client after schema changes pnpm --filter apps-agent-api prisma generate
Production Migration
bash
# Apply pending migrations to production pnpm --filter apps-agent-api prisma migrate deploy
After Migration
bash
# Verify types are correct pnpm typecheck
Naming Conventions
| Entity | Convention | Example |
|---|---|---|
| Models | PascalCase singular | User, Workspace, Agent |
| Fields | camelCase | createdAt, workspaceId |
| Enums | PascalCase | AgentStatus, SubscriptionTier |
Best Practices
Indexes
Always include @@index for frequently queried fields:
prisma
model Agent {
id String @id @default(cuid())
workspaceId String
name String
@@index([workspaceId])
}
Soft Delete Pattern
Use for user-facing entities:
prisma
model User {
id String @id @default(cuid())
deletedAt DateTime?
}
Cascade Delete
Configure appropriately:
prisma
model Agent {
workspace Workspace @relation(fields: [workspaceId], references: [id], onDelete: Cascade)
}
Troubleshooting
| Issue | Solution |
|---|---|
| Migration drift | Run prisma migrate dev to reconcile |
| Shadow database error | Check DATABASE_URL environment variable |
| Type errors after migration | Run pnpm --filter apps-agent-api prisma generate |
Related Files
- •Schema:
/apps/agent-api/prisma/schema.prisma - •Migrations:
/apps/agent-api/prisma/migrations/(read-only) - •Seed:
/apps/agent-api/prisma/seed.ts