agentleFS
KhaledSaeed18KhaledSaeed18/node-express-boilerplate/.agents/skills/update-schema/SKILL.md

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
  1. Distinctive:

    When the user asks to modify the Prisma schema, follow this sequence.

    line 6
  2. Very specific:

    Always set onDelete: explicitly — use Cascade for child records that must not outlive the parent, Restrict or SetNull otherwise

    line 39
  3. Very specific:

    Always add @@index on foreign key columns

    line 46
  4. Distinctive:

    If the migration involves a non-nullable column without a default (data backfill needed):

    line 58
  5. Distinctive:

    After schema changes, update in order:

    line 80

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-only step 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 — use Cascade for child records that must not outlive the parent, Restrict or SetNull otherwise

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 @@index on foreign key columns

Step 2 — Run the migration

pnpm prisma:migrate

This 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 migration

Step 3 — Regenerate the Prisma client

pnpm prisma:generate

This 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:

  1. Types (src/types/) — update DTOs to reflect new/changed fields
  2. Repository — update query select / include clauses, add new methods if needed
  3. Service — update toResponseDTO() mapping, add validation/business logic for new fields
  4. Validation schemas (src/validations/) — add Zod fields for new input fields
  5. Controller — update any response shaping if needed
  6. 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:migrate

Fix 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 database

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.