# Prisma

> FMC Prisma schema conventions: singular PascalCase models, camelCase fields, plural camelCase list relations, singular to-one relations, relation renames, Prisma Client regeneration, and migrations. Use when editing or reviewing schema.prisma in tilda-geo, trassenscout, or sibling FMC apps.

- Skill: `fixmyberlin/prisma` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fixmyberlin/prisma`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fixmyberlin/prisma/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fixmyberlin (https://skillmd.com/u/fixmyberlin)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/fixmyberlin/prisma

---


# Prisma

Use for FMC `schema.prisma` work. Relation field names are Prisma Client API names, not DB names.

## Naming Rules

- Models are PascalCase singular: `User`, `Region`, `QaConfig`.
- All fields are camelCase: `createdAt`, `maskBufferKm`, `regionId`.
- FK scalars use `{name}Id`: `regionId`, `headerLogoId`.
- To-one relations are singular camelCase: `user User`, `contract RegionContract?`.
- To-many relations are plural camelCase: `memberships Membership[]`, `qaConfigs QaConfig[]`.
- DB names belong in `@map` / `@@map`; do not mirror DB naming in Prisma relation fields.

## Relation Rules

- Do not add PascalCase relation fields like `Membership`, `Note`, `LogEntry`.
- Derive simple list names from the related model and pluralize: `Note[]` -> `notes`, `NoteComment[]` -> `noteComments`.
- For multiple relations to the same model, use role names: `projectRecordsAuthored`, `uploadsCreated`.
- Add `@relation("RoleName")` only when Prisma needs disambiguation.
- `@relation("Name")` is only disambiguation, not the Prisma Client field name.
- Prefer readable names for join/assignment models: `categoryAssignments`, `navigationLinks`, `layerConfigs`.

## Audit Rules

- Strongly prefer `createdBy` and `updatedBy` relations on user-edited tables.
- Each always pairs with a FK scalar (`createdById` / `updatedById`): the `*Id` is the DB column; the relation is Prisma Client-only for joins (`include` / `.osmName`) — not a second stored field.
- If table changes need an audit trail beyond `createdBy` / `updatedBy`, use [`@explita/prisma-audit-log`](https://www.npmjs.com/package/@explita/prisma-audit-log) with audit context instead of inventing ad hoc log tables.

## Workflows

Adding schema: add singular model, camelCase scalars, `{name}Id` FK scalars, relation fields by cardinality, named relations for ambiguity, then run `bun prisma generate` or the app script.

Renaming relation fields: rename only in `schema.prisma`; no DB migration is needed for the rename itself. Regenerate Prisma Client, grep old names in `include`, `select`, `_count`, and nested writes, update TypeScript, then run checks.

Undeployed PR-local migrations (several files from one branch that never shipped) may be squashed into the fewest files that express the final schema — skill `unslop-code` → `undeployed-wip.md`. Do not squash migrations already applied to a live DB.

## Related

- DB inspection: skill `tech-stack` -> `references/cursor-mcp.md`
- Better Auth adapter: skill `tanstack-start-auth`
- Undeployed PR-local migration squash: skill `unslop-code` → `references/undeployed-wip.md`

## Sources

- [Prisma schema naming conventions](https://www.prisma.io/docs/orm/reference/prisma-schema-reference#naming-conventions)
- [Prisma custom model and field names](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/custom-model-and-field-names)