update-schema
Skill36 starsChanged 4 months agoMITView on GitHub
Update the Prisma schema to add a new model, add fields to an existing model, or change relations — then run migration and regenerate the client. Use when the user asks to add a field, add a model, change a relation, or update the database schema.
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 6
When the user asks to modify the Prisma schema, follow this sequence.
- Very specific: line 39
Always set onDelete: explicitly — use Cascade for child records that must not outlive the parent, Restrict or SetNull otherwise
- Very specific: line 46
Always add @@index on foreign key columns
- Distinctive: line 58
If the migration involves a non-nullable column without a default (data backfill needed):
- Distinctive: line 80
After schema changes, update in order:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
When the user asks to modify the Prisma schema, follow this sequence.
Step 1 — Edit prisma/schema.prisma
Adding a new model:
model <Name> {
id String @id @default(cuid())
// required fields
// optional fields (mark with ?)
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
// relations
userId String
user User @relation(fields: [userId], references: [id], onDelete: Cascade)
@@index([userId])
@@index([/* other commonly filtered fields */])
@@map("<snake_case_table_name>")
}Adding fields to an existing model:
- Nullable new fields (safest for existing data):
fieldName Type? - Non-nullable with a default:
fieldName Type @default(value) - Non-nullable without a default: requires a migration with a
--create-onlystep to backfill data before applying
Changing relations:
- Adding a one-to-many: add the array field on the "one" side and the FK field + scalar on the "many" side
- Always set
onDelete:explicitly — useCascadefor child records that must not outlive the parent,RestrictorSetNullotherwise
Naming conventions:
- Table names:
@@map("snake_case")on every model - Column names:
@map("snake_case")on every field that differs from the Prisma field name - All IDs:
@id @default(cuid()) - Always add
@@indexon foreign key columns
Step 2 — Run the migration
pnpm prisma:migrateThis creates a new migration file in prisma/migrations/ and applies it to the dev database.
If the migration involves a non-nullable column without a default (data backfill needed):
pnpm exec prisma migrate dev --create-only # generate SQL without applying
# edit the generated SQL to add UPDATE statement for existing rows
pnpm exec prisma migrate deploy # apply the edited migrationStep 3 — Regenerate the Prisma client
pnpm prisma:generateThis must run after every schema change. The generated client lives in src/generated/prisma/.
Step 4 — Update affected TypeScript code
After schema changes, update in order:
- Types (
src/types/) — update DTOs to reflect new/changed fields - Repository — update query
select/includeclauses, add new methods if needed - Service — update
toResponseDTO()mapping, add validation/business logic for new fields - Validation schemas (
src/validations/) — add Zod fields for new input fields - Controller — update any response shaping if needed
- OpenAPI spec — update request/response schemas in
src/docs/
Step 5 — Verify
pnpm full-check
pnpm test
pnpm test:integration # requires pnpm db:test:up + pnpm db:test:migrateFix every error before reporting done. If integration tests fail due to schema mismatch, run:
pnpm db:test:migrate # apply the new migration to the test databaseIn this repository18 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/architecture.mdcCursor rule
- .cursor/rules/conventions.mdcCursor rule
- add-middlewareSkill
- add-openapi-docsSkill
- add-testSkill
- api-design-principlesSkill
- find-skillsSkill
- improveSkill
- multi-stage-dockerfileSkill
- new-resourceSkill
- nodejs-best-practicesSkill
- prisma-client-apiSkill
- prisma-database-setupSkill
- prisma-postgresSkill
- security-auditSkill
- typescript-magicianSkill
- vitestSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

