codeply-cli 0.1.1 → 0.3.0

package/skills/prediction-market-oracle-research/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: prediction-market-oracle-research
+description: Research prediction markets as data sources or oracle signals for products, agents, dashboards, and corporate decision intelligence. Use for source-grounded analysis of market-implied probabilities, caveats, and integration patterns without investment advice.
+metadata:
+  origin: ECC
+---
+
+# Prediction Market Oracle Research
+
+Use this skill when prediction markets are being considered as a data source,
+forecasting input, oracle-like signal, or decision-intelligence layer.
+
+## Guardrails
+
+- Do not treat market prices as objective truth.
+- Do not provide investment advice or trading recommendations.
+- Separate venue mechanics, liquidity, incentives, and resolution rules from the
+  implied signal.
+- Call out manipulation, thin liquidity, stale markets, and ambiguous outcomes.
+- For on-chain or execution-linked systems, run `llm-trading-agent-security`
+  before granting any write authority.
+
+## Research Workflow
+
+1. Define the decision the signal is meant to inform.
+2. Find relevant markets, events, tags, and venues.
+3. Record market-implied probabilities with timestamps and source links.
+4. Evaluate signal quality:
+   - liquidity
+   - spread
+   - market age
+   - trader/incentive concentration if known
+   - resolution authority
+   - geography or account restrictions
+5. Compare against non-market sources such as filings, news, polls, research,
+   customer data, or internal KPIs.
+6. Recommend whether the signal is usable, weak, or unsuitable for the stated
+   decision.
+
+## Integration Patterns
+
+- Research assistant: source-grounded context for a human analyst.
+- Dashboard signal: market-implied probability alongside internal metrics.
+- Agent memory input: a time-stamped signal that can be retrieved later.
+- Alerting input: notify when probabilities, spreads, or liquidity cross a
+  threshold.
+- Scenario planning: compare multiple event outcomes without automating trades.
+
+## Output Contract
+
+Use:
+
+1. decision context
+2. market sources
+3. signal quality
+4. comparison sources
+5. integration recommendation
+6. caveats
+
+End with:
+
+```text
+Prediction-market signals are informational inputs, not investment advice.
+```

package/skills/prediction-market-risk-review/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: prediction-market-risk-review
+description: Review prediction-market, basket, oracle, and trading-agent workflows for compliance, safety, data-quality, privacy, and execution risk. Use before any workflow handles venue auth, user portfolio data, API keys, or trade planning.
+metadata:
+  origin: ECC
+---
+
+# Prediction Market Risk Review
+
+Use this skill before a prediction-market workflow touches user financial
+context, venue authentication, portfolio data, automation, or execution-capable
+tools.
+
+## Review Gates
+
+### Advice Boundary
+
+- Confirm the output is informational.
+- Remove buy/sell/hold/size recommendations.
+- Keep manual user decision points explicit.
+
+### Venue And Regulatory Boundary
+
+- Identify venue terms, geography restrictions, account limits, and API rules.
+- Flag betting, derivatives, securities, or commodities ambiguity for legal
+  review when relevant.
+- Do not bypass venue restrictions or rate limits.
+
+### Data Quality
+
+- Check market liquidity, spread, resolution rules, stale prices, and source
+  timestamps.
+- Separate public venue data from Itô gated data.
+- Do not mix public and private sources without labels.
+
+### Security
+
+- Do not request or store private keys, seed phrases, or passwords.
+- Keep `ITO_API_KEY` and venue API keys out of logs and docs.
+- Use read-only scopes by default.
+- Require circuit breakers, spend limits, dry runs, and human approval before
+  any private implementation adds execution.
+
+### Privacy
+
+- Minimize user portfolio, financial, and knowledge-base data.
+- Redact private sources in public artifacts.
+- Preserve only the fields needed for the review.
+
+## Output Contract
+
+Return:
+
+1. scope reviewed
+2. pass/warn/fail findings
+3. blocked actions
+4. required mitigations
+5. safe next step
+
+If any execution-capable step is requested, require a separate implementation
+plan and explicit user approval.

package/skills/premium-web-design/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: premium-web-design
+description: Codeply's default visual bar for any website, landing page, or UI it generates — vanilla HTML/CSS/JS techniques (type, color, depth, scroll-triggered motion, subtle 3D) that make even a trivial brief (a tea shop, a local plumber, a one-page portfolio) read as an expensive, art-directed build instead of a templated AI scaffold. Use for every "build me a website / page / landing site" request, no matter how small the business sounds — small brief is not license for a flat result.
+metadata:
+  origin: codeply
+---
+
+# Premium Web Design
+
+The gap between "a website" and "a website that looks like it cost $10k" is not
+more content. It is five things done deliberately instead of by default: type,
+color, depth, motion, and restraint. This skill is the checklist that turns a
+plain-HTML brief — a tea shop, a barber, a two-person agency — into something
+that reads as art-directed. Apply it **even when the user's request is one
+sentence and sounds trivial.** The size of the brief is not license for a flat
+result; a tea shop site gets the same craft pass as a SaaS landing page.
+
+## When to Use
+
+Any time you are about to write or restyle HTML/CSS for a page a human will
+look at: landing pages, marketing sites, portfolios, small-business sites,
+dashboards, docs, artifacts. If the deliverable renders in a browser and has
+no explicit "keep it minimal/utilitarian" instruction from the user, this
+skill applies by default — do not wait to be asked for "premium" or
+"animated."
+
+## The Five Levers
+
+### 1. Type — pick a pairing, not a default
+
+Never ship `system-ui` / Arial as the whole identity. Pick ONE deliberate
+pairing and commit:
+- Editorial: a serif display (Fraunces, Playfair Display, Instrument Serif) +
+  a clean grotesk body (Inter, General Sans, Geist).
+- Technical/modern: one variable grotesk (Inter, Geist, Söhne-alike) at two
+  weights, huge size contrast between hero and body.
+- Warm/local business (cafés, shops, studios): a humanist serif or friendly
+  display headline + a quiet sans body — avoid corporate SaaS grotesk here,
+  it reads generic for a tea shop.
+
+Rules: headline sizes should feel oversized relative to instinct (clamp with
+`clamp(2.5rem, 6vw, 5.5rem)`), line-height tight on display type (1.0–1.1),
+loose on body (1.5–1.7), and letter-spacing slightly negative on large type
+(`-0.02em` to `-0.04em`). Import via `@font-face`/Google Fonts `<link>` —
+never leave it at the browser default.
+
+### 2. Color — a system, not a palette guess
+
+Ban: purple-to-blue gradient hero, pure `#000`/`#fff` with a single accent
+blue, "AI slop" default (indigo #6366f1 / violet #8b5cf6 on white cards).
+Instead build a small token system from the domain:
+- 1 base neutral (often warm, not pure gray — `#f7f4ee`, `#111014`)
+- 1 ink color for text (rarely pure black — try a near-black with a hue lean)
+- 1–2 brand colors pulled from the actual subject (a tea shop: terracotta,
+  moss, cream, not tech-blue)
+- 1 accent used sparingly (links, one CTA, one highlight) — not on every card
+
+Define them as CSS custom properties on `:root` and reuse everywhere; that
+alone makes a page look designed instead of assembled.
+
+### 3. Depth — layered, not flat-card-grid
+
+Avoid the default "grid of identical white cards with a drop-shadow" — it is
+the single most recognizable AI-generated-site tell. Instead:
+- Vary section backgrounds (alternate base/ink/tinted sections) so the page
+  has rhythm when you scroll, not one long white column.
+- Use large background shapes, subtle grain/noise texture, or a soft radial
+  glow behind hero content instead of a flat solid fill.
+- Layer real photography or generated imagery behind translucent panels
+  (`backdrop-filter: blur(16px)`, semi-opaque background) for a glass feel
+  where it fits the brand — skip it for utilitarian dashboards.
+- Give the hero one asymmetric or oversized element (an oversized product
+  shot bleeding off-canvas, an angled image, a big pull-quote) instead of
+  centered text + centered image every time.
+
+**Imagery must be on-topic, not just present.** A hero image is worse than no
+image if it's unrelated to the subject — a beach photo on a tea brand's
+"Our Heritage" section reads as more broken than a placeholder color block,
+because it actively contradicts the copy next to it. When fetching stock
+imagery with `fetch_image`, use a keyword-searchable source
+(`https://loremflickr.com/<w>/<h>/<keyword1>,<keyword2>`) and pick keywords
+per-section from that section's actual subject — never a fully-random source
+like picsum.photos on a themed site. A tea shop's hero gets `tea,leaves` or
+`teapot,ceremony`, a product card for oolong gets `oolong,tea`, not one
+generic keyword reused everywhere or no keyword at all. If no source can be
+made reliably on-topic for a given spot (an odd or very specific subject),
+prefer a solid-color/gradient placeholder panel over a wrong photo, and say
+so to the user.
+
+### 4. Motion — scroll-triggered, physical, restrained
+
+A static page reads cheap even with good type/color. Add motion with plain
+CSS/JS (no framework required):
+
+```css
+.reveal { opacity: 0; transform: translateY(24px); transition: opacity .7s cubic-bezier(.16,1,.3,1), transform .7s cubic-bezier(.16,1,.3,1); }
+.reveal.is-visible { opacity: 1; transform: translateY(0); }
+@media (prefers-reduced-motion: reduce) { .reveal { transition: none; opacity: 1; transform: none; } }
+```
+
+```js
+const io = new IntersectionObserver((entries) => {
+  for (const e of entries) if (e.isIntersecting) e.target.classList.add('is-visible');
+}, { threshold: 0.15 });
+document.querySelectorAll('.reveal').forEach((el) => io.observe(el));
+```
+
+Layer in: a subtle parallax on the hero image (`transform: translateY()`
+tied to scroll position, small range like 20–40px), a hover tilt on cards
+(`transform: perspective(800px) rotateX() rotateY()` from pointer position,
+a cheap but convincing "3D" feel), and a smooth `scroll-behavior: smooth` for
+anchor nav. Stagger reveal delays across siblings (`transition-delay` +
+`nth-child`) instead of everything fading in at once — staggering is what
+makes a section feel choreographed rather than triggered.
+
+Always respect `prefers-reduced-motion`. Keep transitions 200–700ms;
+snappy for hover/press, slower for scroll reveals.
+
+### 5. Restraint — the difference between premium and busy
+
+- One hero move, one card-hover move, one scroll-reveal pattern — reused
+  consistently, not five different animation styles competing.
+  `frontend-design-direction` has the anti-pattern list (no cards-in-cards,
+  no gradient blobs, no vague hero copy) — use_skill it too on larger builds.
+- Whitespace is a design choice, not leftover space: generous section
+  padding (`clamp(4rem, 10vw, 8rem)` vertical), generous gaps in grids.
+  Cramped sections are the second most common AI-slop tell after flat cards.
+- Real, specific copy beats generic copy: name the actual product (single-
+  origin oolong, not "our amazing products"), and if there's no CMS/content
+  yet, write copy that sounds like this specific business, not a template.
+
+## Quick Pre-Ship Checklist
+
+- Is there a real font pairing, or did I leave system defaults?
+- Is the palette pulled from the subject, or is it default-AI indigo/violet?
+- Does the hero have one asymmetric/oversized visual idea, or is everything
+  centered and evenly sized?
+- Does anything move on scroll or hover, or is the page fully static?
+- Are sections visually differentiated (background/rhythm), or one flat
+  white column of same-size cards?
+- Would this specific business (a tea shop, not "a company") recognize
+  itself in the copy and color choices?
+
+If any answer is "no," the build is not done — go back and apply the lever
+before calling it finished.
+
+## Related Skills
+
+- `frontend-design-direction` — direction-setting discipline (purpose,
+  audience, tone, anti-patterns) for larger or more product-y builds.
+- `motion-ui`, `motion-foundations`, `motion-patterns` — deeper motion system
+  for React/Next.js projects specifically (this skill's motion section is the
+  framework-free equivalent for plain HTML/CSS/JS builds).
+- `frontend-a11y` — accessibility pass once the visual direction is set.

package/skills/prisma-patterns/SKILL.md

@@ -0,0 +1,401 @@
+---
+name: prisma-patterns
+description: Prisma ORM patterns for TypeScript backends — schema design, query optimization, transactions, pagination, and critical traps like updateMany returning count not records, $transaction timeouts, migrate dev resetting the DB, @updatedAt skipped on bulk writes, and serverless connection exhaustion.
+metadata:
+  origin: ECC
+---
+
+# Prisma Patterns
+
+Production patterns and non-obvious traps for Prisma ORM in TypeScript backends.
+
+> **Check your version before applying patterns.** The Prisma API surface has evolved across major releases:
+>
+> ```bash
+> npx prisma --version
+> ```
+>
+> Notable API differences across versions:
+> - `relationJoins` can load relations via JOIN rather than separate queries, but may cause row explosion on large 1:N relations or deep `include` — benchmark both approaches
+> - `omit` field modifier and `prisma.$extends` Client Extensions API were added
+> - **Newer installs**: the package may be named `prisma` instead of `@prisma/client`; `PrismaClient` may require a driver adapter (e.g. `@prisma/adapter-pg`); `datasource.url` may live in `prisma.config.ts` instead of `schema.prisma`
+> - CLI commands (`migrate dev`, `migrate deploy`, `generate`) are unchanged across versions
+
+## When to Activate
+
+- Designing or modifying Prisma schema models and relations
+- Writing queries, transactions, or pagination logic
+- Using `updateMany`, `deleteMany`, or any bulk operation
+- Running or planning database migrations
+- Deploying to serverless environments (Vercel, Lambda, Cloudflare Workers)
+- Implementing soft delete or multi-tenant row filtering
+
+## Core Concepts
+
+### ID Strategy
+
+| Strategy | Use When | Avoid When |
+|---|---|---|
+| `@default(cuid())` | Default choice — URL-safe, sortable, no collisions | Sequential IDs needed for external systems |
+| `@default(uuid())` | Interoperability with non-Prisma systems required | High-write tables (random UUIDs fragment B-tree indexes) |
+| `@default(autoincrement())` | Internal join tables, audit logs | Public-facing IDs (exposes record count) |
+
+### Schema Defaults
+
+```prisma
+model User {
+  id        String    @id @default(cuid())
+  email     String    @unique  // @unique already creates an index — no @@index needed
+  name      String
+  role      Role      @default(USER)
+  posts     Post[]
+  createdAt DateTime  @default(now())
+  updatedAt DateTime  @updatedAt
+  deletedAt DateTime?
+
+  @@index([createdAt])
+  @@index([deletedAt, createdAt]) // composite for soft-delete + sort queries
+}
+```
+
+- Add `@@index` on every foreign key and column used in `WHERE` or `ORDER BY`.
+- Declare `deletedAt DateTime?` upfront when soft delete is a foreseeable requirement — adding it later requires a migration on a live table.
+- `updatedAt @updatedAt` is set automatically by Prisma on `update` and `upsert` only (see Anti-Patterns for bulk update trap).
+
+### `include` vs `select`
+
+| | `include` | `select` |
+|---|---|---|
+| Returns | All scalar fields + specified relations | Only specified fields |
+| Use when | You need most fields plus a relation | Hot paths, large tables, avoiding over-fetch |
+| Performance | May over-fetch on wide tables | Minimal payload, faster on large datasets |
+| Prisma 5 note | Uses JOIN by default (`relationJoins`) | Same |
+
+```ts
+// include — all columns + relation
+const user = await prisma.user.findUnique({
+  where: { id },
+  include: { posts: { select: { id: true, title: true } } },
+});
+
+// select — explicit allowlist
+const user = await prisma.user.findUnique({
+  where: { id },
+  select: { id: true, email: true, name: true },
+});
+```
+
+Never return raw Prisma entities from API responses — map to response DTOs to control exposed fields:
+
+```ts
+// BAD: leaks passwordHash, deletedAt, internal fields
+return await prisma.user.findUniqueOrThrow({ where: { id } });
+
+// GOOD: explicit DTO mapping
+const user = await prisma.user.findUniqueOrThrow({ where: { id } });
+return { id: user.id, name: user.name, email: user.email };
+```
+
+### Transaction Form Selection
+
+| Situation | Use |
+|---|---|
+| Independent operations, no inter-dependency | Array form |
+| Later step depends on earlier result | Interactive form |
+| External calls (email, HTTP) involved | Outside transaction entirely |
+
+```ts
+// Array form — batched in one round trip
+const [user, post] = await prisma.$transaction([
+  prisma.user.update({ where: { id }, data: { name } }),
+  prisma.post.create({ data: { title, authorId: id } }),
+]);
+
+// Interactive form — use tx client only, never the outer prisma client
+const post = await prisma.$transaction(async (tx) => {
+  const user = await tx.user.findUniqueOrThrow({ where: { id } });
+  if (user.role !== 'ADMIN') throw new Error('Forbidden');
+  return tx.post.create({ data: { title, authorId: user.id } });
+});
+```
+
+### PrismaClient Singleton
+
+Each `PrismaClient` instance opens its own connection pool. Instantiate once.
+
+```ts
+// lib/prisma.ts
+
+// Option A — adapter-based initialization (required by newer Prisma installs)
+import { PrismaClient } from '@prisma/client'; // or the generated client path for your setup
+import { PrismaPg } from '@prisma/adapter-pg';
+
+function createPrismaClient() {
+  const adapter = new PrismaPg({
+    connectionString: process.env.DATABASE_URL!,
+  });
+  return new PrismaClient({
+    adapter,
+    log: process.env.NODE_ENV === 'development' ? ['query', 'error'] : ['error'],
+  });
+}
+
+const globalForPrisma = globalThis as unknown as { prisma?: PrismaClient };
+
+export const prisma = globalForPrisma.prisma ?? createPrismaClient();
+
+if (process.env.NODE_ENV !== 'production') globalForPrisma.prisma = prisma;
+
+// Option B — direct initialization (older installs, no adapter needed)
+// import { PrismaClient } from '@prisma/client';
+// export const prisma = globalForPrisma.prisma ?? new PrismaClient({ ... });
+```
+
+Use Option A if your Prisma install requires an `adapter` argument in the `PrismaClient` constructor.
+Use Option B if `new PrismaClient()` works without arguments. Let the compiler tell you which is correct.
+
+The `globalThis` pattern prevents duplicate instances during hot reload (Next.js, nodemon, ts-node-dev).
+
+### N+1 Problem
+
+Loading relations inside a loop issues one query per row.
+
+```ts
+// BAD: N+1 — one extra query per user
+const users = await prisma.user.findMany();
+for (const user of users) {
+  const posts = await prisma.post.findMany({ where: { authorId: user.id } });
+}
+
+// GOOD: single query
+const users = await prisma.user.findMany({ include: { posts: true } });
+```
+
+With Prisma 5+ `relationJoins`, the `include` form uses a single JOIN. On large 1:N sets this may increase result set size — benchmark both approaches if the relation can return many rows per parent.
+
+## Code Examples
+
+### Cursor Pagination (preferred for feeds and large datasets)
+
+```ts
+async function getPosts(cursor?: string, limit = 20) {
+  const items = await prisma.post.findMany({
+    where: { published: true },
+    orderBy: [
+      { createdAt: 'desc' },
+      { id: 'desc' }, // secondary sort prevents unstable pagination on duplicate timestamps
+    ],
+    take: limit + 1,
+    ...(cursor && { cursor: { id: cursor }, skip: 1 }),
+  });
+
+  const hasNextPage = items.length > limit;
+  if (hasNextPage) items.pop();
+
+  return { items, nextCursor: hasNextPage ? items[items.length - 1].id : null };
+}
+```
+
+Fetch `limit + 1` and pop — canonical way to detect `hasNextPage` without an extra count query. Always include a unique field (e.g. `id`) as a secondary `orderBy` to prevent unstable pagination when multiple rows share the same timestamp. Use offset pagination only when users need to jump to arbitrary pages (admin tables).
+
+### Soft Delete
+
+```ts
+// Always filter explicitly — do not rely on middleware (hides behavior, hard to debug)
+const activeUsers = await prisma.user.findMany({ where: { deletedAt: null } });
+
+await prisma.user.update({ where: { id }, data: { deletedAt: new Date() } });
+await prisma.user.update({ where: { id }, data: { deletedAt: null } }); // restore
+```
+
+### Error Handling
+
+```ts
+import { Prisma } from '@prisma/client'; // or the generated client path for your setup
+
+try {
+  await prisma.user.create({ data: { email } });
+} catch (e) {
+  if (e instanceof Prisma.PrismaClientKnownRequestError) {
+    if (e.code === 'P2002') throw new ConflictError('Email already exists');
+    if (e.code === 'P2025') throw new NotFoundError('Record not found');
+    if (e.code === 'P2003') throw new BadRequestError('Referenced record does not exist');
+  }
+  throw e;
+}
+```
+
+Common codes: `P2002` unique violation · `P2025` not found · `P2003` foreign key violation.
+
+Catch at the service boundary and translate to domain errors. Never expose raw Prisma messages to API consumers.
+
+### Connection Pool — Serverless
+
+Embed connection params directly in `DATABASE_URL` — string concatenation breaks if the URL already has query parameters (e.g. `?schema=public`):
+
+```bash
+# .env — preferred: embed params in the URL
+DATABASE_URL="postgresql://user:pass@host/db?connection_limit=1&pool_timeout=20"
+
+# With an external pooler (PgBouncer, Supabase pooler)
+DATABASE_URL="postgresql://user:pass@host/db?pgbouncer=true&connection_limit=1"
+```
+
+```ts
+// Vercel, AWS Lambda, and similar serverless runtimes:
+// cap pool to 1 per instance; connection_limit and pool_timeout controlled via DATABASE_URL
+
+// Adapter-based setup (if your Prisma install requires an adapter):
+import { PrismaClient } from '@prisma/client';
+import { PrismaPg } from '@prisma/adapter-pg';
+
+const prisma = new PrismaClient({
+  adapter: new PrismaPg({ connectionString: process.env.DATABASE_URL }),
+});
+
+// Direct setup (if your Prisma install does not require an adapter):
+// const prisma = new PrismaClient();
+```
+
+## Anti-Patterns
+
+### `updateMany` returns a count, not records
+
+```ts
+// BAD: result is { count: 2 } — users[0] is undefined
+const users = await prisma.user.updateMany({ where: { role: 'GUEST' }, data: { role: 'USER' } });
+
+// GOOD: capture IDs first, then update, then fetch only the affected rows
+const targets = await prisma.user.findMany({
+  where: { role: 'GUEST' },
+  select: { id: true },
+});
+const ids = targets.map((u) => u.id);
+await prisma.user.updateMany({ where: { id: { in: ids } }, data: { role: 'USER' } });
+const updated = await prisma.user.findMany({ where: { id: { in: ids } } });
+```
+
+Same applies to `deleteMany` — returns `{ count: n }`, never the deleted rows.
+
+### `$transaction` interactive form times out after 5 seconds
+
+```ts
+// BAD: external call inside transaction exceeds 5s default → "Transaction already closed"
+await prisma.$transaction(async (tx) => {
+  const user = await tx.user.findUniqueOrThrow({ where: { id } });
+  await sendWelcomeEmail(user.email); // external call
+  await tx.user.update({ where: { id }, data: { emailSent: true } });
+});
+
+// GOOD: external calls outside the transaction
+const user = await prisma.user.findUniqueOrThrow({ where: { id } });
+await sendWelcomeEmail(user.email);
+await prisma.user.update({ where: { id }, data: { emailSent: true } });
+
+// Only raise timeout when bulk processing genuinely needs it
+await prisma.$transaction(async (tx) => { ... }, { timeout: 30_000 });
+```
+
+### `migrate dev` can reset the database
+
+`migrate dev` detects schema drift and may prompt to reset the DB, dropping all data.
+
+```bash
+# NEVER on shared dev, staging, or production
+npx prisma migrate dev --name add_column
+
+# Safe everywhere except local solo dev
+npx prisma migrate deploy
+
+# Check drift without applying
+npx prisma migrate diff \
+  --from-migrations ./prisma/migrations \
+  --to-schema-datamodel ./prisma/schema.prisma \
+  --shadow-database-url "$SHADOW_DATABASE_URL"
+```
+
+### Manually editing a migration file breaks future deploys
+
+Prisma checksums every migration file. Editing after apply causes `P3006 checksum mismatch` on every environment where the original already ran. Create a new migration instead.
+
+### Breaking schema changes require multi-step migration
+
+Adding `NOT NULL` to an existing column or renaming a column in one migration will lock the table or drop data. Use expand-and-contract:
+
+```bash
+# Step 1: create migration locally, then deploy
+npx prisma migrate dev --name add_new_column   # local only
+npx prisma migrate deploy                       # staging / production
+```
+
+```ts
+// Step 2: backfill data (run in a script or migration job, not in the shell)
+await prisma.user.updateMany({ data: { newColumn: derivedValue } });
+```
+
+```bash
+# Step 3: create the NOT NULL constraint migration locally, then deploy
+npx prisma migrate dev --name make_new_column_required  # local only
+npx prisma migrate deploy                               # staging / production
+```
+
+### `@updatedAt` does not fire on `updateMany`
+
+`@updatedAt` is set automatically only on `update` and `upsert`. Bulk writes leave it stale.
+
+```ts
+// BAD: updatedAt stays at its old value
+await prisma.post.updateMany({ where: { authorId }, data: { published: true } });
+
+// GOOD
+await prisma.post.updateMany({
+  where: { authorId },
+  data: { published: true, updatedAt: new Date() },
+});
+```
+
+### Soft delete + `findUniqueOrThrow` leaks deleted records
+
+`findUniqueOrThrow` throws `P2025` only when the row does not exist in the DB. Soft-deleted rows still exist and are returned without error.
+
+`findUniqueOrThrow` requires a unique constraint field in `where` — adding `deletedAt: null` alongside `id` breaks the type because `{ id, deletedAt }` is not a compound unique constraint. Use `findFirstOrThrow` instead.
+
+```ts
+// BAD: returns soft-deleted user
+const user = await prisma.user.findUniqueOrThrow({ where: { id } });
+
+// BAD: Prisma type error — { id, deletedAt } is not a unique constraint
+const user = await prisma.user.findUniqueOrThrow({ where: { id, deletedAt: null } });
+
+// GOOD: findFirstOrThrow supports arbitrary where conditions
+const user = await prisma.user.findFirstOrThrow({ where: { id, deletedAt: null } });
+```
+
+### `deleteMany` without `where` deletes every row
+
+```ts
+// BAD: silently wipes the table
+await prisma.post.deleteMany();
+
+// GOOD
+await prisma.post.deleteMany({ where: { authorId: userId } });
+```
+
+## Best Practices
+
+| Rule | Reason |
+|---|---|
+| `migrate deploy` in CI/CD, `migrate dev` only locally | `migrate dev` can reset the DB on drift |
+| Map entities to response DTOs | Prevents leaking internal fields |
+| Catch `PrismaClientKnownRequestError` at service boundary | Translate to domain errors |
+| Prefer `*OrThrow` methods over manual null checks | Throws P2025 automatically; use `findFirstOrThrow` when filtering non-unique fields |
+| `connection_limit=1` + external pooler in serverless | Prevents connection exhaustion |
+| Always provide `where` on `deleteMany` | Prevents accidental table wipe |
+| Set `updatedAt: new Date()` manually in `updateMany` | `@updatedAt` skips bulk writes |
+
+## Related Skills
+
+- `nestjs-patterns` — NestJS service layer that integrates Prisma
+- `postgres-patterns` — PostgreSQL-level indexing and connection tuning
+- `database-migrations` — multi-step migration planning for production
+- `backend-patterns` — general API and service layer design