@agilno-tech/rivet 0.1.0-alpha.0

package/dist/mandatory/security-review/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: rivet-security-review
+description: "Audit code, APIs, or infrastructure for security vulnerabilities — authentication flaws,"
+---
+
+# Security Review
+
+Audit code, APIs, or infrastructure for security vulnerabilities — authentication flaws,
+injection risks, data exposure, and OWASP Top 10 issues. Runs standalone on demand, and is
+also auto-invoked by `/pre-push` and `/review-pr` whenever a diff touches an auth, payment,
+or user-data path.
+
+## Usage
+
+```
+/security-review
+/security-review <path, file glob, or diff range>
+```
+
+With no argument, review the current diff against the default branch. `/pre-push` and
+`/review-pr` invoke this skill's checklist inline against their own diff — they do not shell
+out to a separate `/security-review` call, but the checklist below is the shared source of
+truth both use.
+
+---
+
+## Instructions
+
+1. Determine scope:
+   - Explicit path/glob argument → review those files.
+   - Diff range argument → review the diff.
+   - No argument → `git diff origin/<default-branch>...HEAD`.
+   - Invoked internally by `/pre-push` or `/review-pr` → scope is whatever files/diff the
+     caller already flagged as touching a sensitive path.
+
+2. Identify context needed to apply the checklist accurately:
+   - Application type (web API / mobile backend / internal tool / public-facing)
+   - Auth mechanism (JWT / session / OAuth / API key) — infer from the codebase or `CLAUDE.md`
+   - Data sensitivity (PII / financial / healthcare / low) — check `CLAUDE.md`'s Sensitive
+     Areas section
+   - Framework — NestJS / Django / Next.js / other, for the framework-specific checklist notes
+
+3. Apply every relevant item in the Security Checklist below. Skip items that don't apply to
+   the stack or the code in scope — do not report N/A items as findings.
+
+4. Output format (matches `/pre-push` and `/review-pr` severity conventions):
+
+   ```
+   ## Security Review
+
+   ### 🔴 Critical
+   (must fix before shipping — injection, auth bypass, data exposure)
+   - <file:line> — <OWASP category> — <what's wrong> — <fix>
+
+   ### 🟡 Warnings
+   (should fix soon — weak validation, missing rate limiting)
+   - <file:line> — <OWASP category> — <what's wrong> — <fix>
+
+   ### 🟢 Recommendations
+   (hardening — CSP headers, input sanitization, logging)
+   - <file:line> — <suggestion>
+
+   ### Verification
+   How to confirm each Critical/Warning fix works (test cases, tools/commands to run).
+   ```
+
+5. If called from `/pre-push` or `/review-pr`, return only the 🔴/🟡 findings for merging into
+   the caller's own Findings section — the caller keeps its own report format and severity
+   levels; don't emit a second, separate report block.
+
+---
+
+## Security Checklist
+
+Each item is tagged with the relevant [OWASP Top 10 2021](https://owasp.org/Top10/) category:
+**A01** Broken Access Control · **A02** Cryptographic Failures · **A04** Insecure Design · **A05** Security Misconfiguration · **A07** Identification & Authentication Failures · **A09** Security Logging & Monitoring Failures
+
+Items marked **[NestJS]**, **[Django]**, or **[Next.js]** have framework-specific notes. Everything else applies to any stack.
+
+---
+
+### Auth & Tokens — A07
+
+- [ ] **Refresh tokens in httpOnly cookies, not localStorage** — any XSS script can read `localStorage`. Cookie must have `httpOnly: true`, `Secure: true` (HTTPS), `SameSite: Strict`, and `Path` scoped to the auth route (e.g., `/v1/auth`).
+  - **[NestJS]** Use `cookie-parser` middleware + `res.cookie(name, value, options)` in the auth controller. Frontend must pass `credentials: "include"` on all fetch calls.
+  - **[Django]** Set `SESSION_COOKIE_HTTPONLY = True`, `SESSION_COOKIE_SECURE = True`, `SESSION_COOKIE_SAMESITE = "Strict"` in `settings.py`. For JWT, write the token in a view using `response.set_cookie(...)` with same flags.
+
+- [ ] **Rate limiting on all auth endpoints** — minimum: register ≤3/min, login ≤5/min, forgot-password ≤3/min, reset-password ≤5/min.
+  - **[NestJS]** `ThrottlerGuard` must be registered as `APP_GUARD` in `AppModule` (configuring it without registering the guard has no effect). Add `@Throttle({ default: { ttl: 60000, limit: 5 } })` per endpoint.
+  - **[Django]** Use `django-ratelimit` (`@ratelimit` decorator) or DRF's `DEFAULT_THROTTLE_CLASSES` with `AnonRateThrottle`/`UserRateThrottle`. For brute-force lockout use `django-axes`.
+
+- [ ] **Password complexity beyond min length** — `@MinLength(8)` or `min_length=8` alone allows "12345678". Require at least 1 uppercase, 1 lowercase, 1 digit.
+  - **[NestJS]** `@Matches(/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)/)` on register and reset-password DTOs.
+  - **[Django]** Add `MinimumLengthValidator` + custom `validate()` function in `AUTH_PASSWORD_VALIDATORS`.
+
+- [ ] **Password reset tokens hashed in DB** — store `SHA-256(token)`, send the raw token by email. A DB breach must not allow password reset for any account.
+
+- [ ] **Refresh token reuse detection** — when a used token is re-presented, invalidate the entire token family (all sessions for that login chain) and log a warning. Deleting only the latest token on refresh is insufficient.
+
+- [ ] **Session/presence cookies HMAC-signed** — a cookie whose value is only checked for presence (`if (!cookie?.value)`) can be forged with `document.cookie = "session=1"`. The value must include a timestamp + HMAC-SHA256 signature verified server-side.
+  - **[Next.js]** Verify in `middleware.ts` (or `proxy.ts` for Next.js 16+) using `crypto.subtle`.
+
+- [ ] **2FA partial tokens not in sessionStorage** — `sessionStorage` is accessible to XSS. Pass via URL query param (`/verify-2fa?t=<token>`) or keep in React state only.
+
+---
+
+### Input Validation & Mass Assignment — A04
+
+- [ ] **Validated schema objects on all request bodies** — TypeScript type annotations (`body: { name?: string }`) are erased at runtime. Inline interfaces provide no runtime validation.
+  - **[NestJS]** Always use class-validator DTOs with `@Body() dto: MyDto`. Without this, `ValidationPipe({ whitelist: true })` cannot strip/reject extra fields, enabling mass assignment.
+  - **[Django/DRF]** Always use a serializer class — never pass `request.data` directly to `Model.objects.create(**data)`. Set `read_only_fields` to prevent privilege escalation via writable fields.
+
+- [ ] **UUID validation on all ID params** — reject malformed IDs at the routing layer before they reach the DB.
+  - **[NestJS]** `@Param('id', ParseUUIDPipe)` on every `:id` route param. `@IsUUID()` on UUID fields in DTOs (not just `@IsString()`).
+  - **[Django]** Use `<uuid:pk>` URL converter. DRF `UUIDField` on serializer fields.
+
+- [ ] **No raw SQL with string interpolation** — use parameterized queries.
+  - **[NestJS/Prisma]** Use `` $queryRaw`SELECT * FROM t WHERE id = ${id}` `` (tagged template), not `$queryRawUnsafe`.
+  - **[Django]** Use `Model.objects.filter(id=id)` or `cursor.execute(sql, [param])`, never `f"... WHERE id = {id}"`.
+
+---
+
+### Secrets & Cryptography — A02
+
+- [ ] **Sensitive third-party config encrypted at rest** — fields like `apiKey`, `botToken`, `password`, `secret` in an integration/connector config table must be encrypted before DB persistence (AES-256-GCM or equivalent), not stored as plain JSON. A DB dump or SQL injection must not expose all third-party credentials.
+
+- [ ] **No PII in log messages** — log generic messages for missing/invalid account scenarios. Write `"password reset for non-existent account"`, not `"password reset for ${email}"`.
+
+---
+
+### Authorization & Tenant Isolation — A01
+
+- [ ] **Tenant ID from JWT, not request** — extract `tenantId` from the verified JWT payload, never from request body, query params, or headers. Trusting client-supplied tenant context allows cross-tenant data access.
+  - **[NestJS]** `@CurrentUser('tenantId')` decorator.
+  - **[Django]** Read from `request.user.tenant_id` set by the authentication backend; reject any `tenant_id` in the request body for scoped queries.
+
+- [ ] **All execution paths go through the same authorization layer** — if there is an AI assistant flow and a direct API endpoint performing the same action, both must evaluate the same rules/permissions. Direct API shortcuts that bypass the rules engine are a full authorization bypass.
+
+- [ ] **CORS blocks localhost in production** — `http://localhost:*` in the CORS allowlist in production allows local malware or browser extensions to send authenticated cross-origin requests. Allow localhost only when `NODE_ENV !== "production"`.
+
+---
+
+### Security Logging — A09
+
+- [ ] **Audit log user ID field matches JWT payload field names** — if the JWT strategy returns `{ id, tenantId }`, the audit interceptor must read `user.id`, not `user.userId`. A field name mismatch silently writes `null` to every audit record, making forensic investigation impossible.
+
+---
+
+### Headers & Configuration — A05
+
+- [ ] **HTTP security headers active on the backend**
+  - **[NestJS]** `app.use(helmet())` in `main.ts` — covers CSP, HSTS, `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy`.
+  - **[Django]** `django.middleware.security.SecurityMiddleware` + `SECURE_HSTS_SECONDS`, `SECURE_CONTENT_TYPE_NOSNIFF`, `X_FRAME_OPTIONS = "DENY"`, `django-csp` for Content-Security-Policy.
+
+- [ ] **Next.js security headers in `next.config.ts`** — add a `headers()` export with at minimum: `X-Frame-Options: DENY`, `X-Content-Type-Options: nosniff`, `Strict-Transport-Security`, `Content-Security-Policy`, `Referrer-Policy`, `Permissions-Policy`.
+
+- [ ] **Auth state directories restricted** — directories storing session keys or auth state files on disk (e.g., OAuth tokens, bot session data) must be `chmod 700` and owned by the service user, not world-readable.

package/dist/skills/api-contract/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: rivet-api-contract
+description: "Designing or reviewing API endpoints and schemas; ensuring backward compatibility; writing OpenAPI/Swagger summaries."
+---
+
+# Skill: API & Contract
+
+## When to use
+Designing or reviewing API endpoints and schemas; ensuring backward compatibility; writing OpenAPI/Swagger summaries.
+
+## Prompt template
+You are acting as an API designer.
+
+Context:
+- Consumers include web and mobile clients
+- Stability matters: avoid breaking changes
+- Align naming and error formats with existing APIs
+
+Task:
+[DESCRIBE ENDPOINT OR CONTRACT CHANGE]
+
+Output:
+- Method + path (or GraphQL operation)
+- Request schema (query/body)
+- Response schema (success + error)
+- Versioning/backward compatibility notes
+- Examples (1 request/response)
+
+---
+
+## API Contract Standards (enforce on all endpoints)
+
+### Response Envelope
+
+All endpoints must return a consistent envelope:
+
+```json
+{ "success": true, "data": { ... } }
+{ "success": false, "error": { "code": "VALIDATION_ERROR", "message": "..." } }
+```
+
+Exception: auth token endpoints (login/register/refresh) may return flat `{ accessToken, expiresIn }` if changing would break existing clients.
+
+### Tenant Isolation
+
+- Extract `tenantId` from the JWT (`@CurrentUser('tenantId')`), never from request body or query params.
+- Every list/get/mutation endpoint must scope DB queries by `tenantId`.
+- Shared infrastructure endpoints (health, servers, system bots) must still require authentication even if data is not per-tenant.
+
+### Pagination on List Endpoints
+
+Every endpoint returning a collection must support pagination:
+
+```text
+GET /resource?limit=50&offset=0
+```
+
+- Default limit: 50
+- Max limit: 100 (server-side clamp: `Math.min(Math.max(limit, 1), 100)`)
+- Response: `{ entries: [...], total: N, limit: 50, offset: 0 }`
+- Exception: endpoints where the result set is provably bounded (e.g., per-tenant connectors, likely ≤20 items)
+
+### HTTP Status Codes
+
+| Operation | Status |
+| --------- | ------ |
+| POST (create) | 201 Created |
+| GET, PATCH, PUT | 200 OK |
+| DELETE | 200 OK (with body) or 204 No Content |
+| Rate limit exceeded | 429 Too Many Requests |
+| Rules engine deny | 403 Forbidden |
+| Validation failure | 400 Bad Request |
+
+### Param Validation
+
+- All `:id` path params: `@Param('id', ParseUUIDPipe)` — rejects non-UUID strings before DB layer
+- Query params with type expectations: use `@Query('limit', new DefaultValuePipe(50), ParseIntPipe)`

package/dist/skills/backend-django/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: rivet-backend-django
+description: "For implementing or extending Django + Django REST Framework backend features including models, serializers, views, perm"
+---
+
+# Skill: Backend (Django / DRF)
+
+## When to use
+For implementing or extending Django + Django REST Framework backend features including models, serializers, views, permissions, and migrations.
+
+## Prompt template
+You are acting as a senior Django backend engineer.
+
+Context:
+- Framework: Django + Django REST Framework
+- Follow existing project structure and naming conventions
+- Prefer serializers for validation and API contracts
+- Maintain backward compatibility unless explicitly requested
+
+Task:
+[DESCRIBE BACKEND TASK]
+
+Output:
+- Proposed approach
+- Django code (models, serializers, views, urls)
+- Migration notes if required
+- Edge cases and validation considerations

package/dist/skills/backend-nestjs/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: rivet-backend-nestjs
+description: "For implementing or extending NestJS services (REST or GraphQL), controllers/resolvers, DTO validation, modules, and int"
+---
+
+# Skill: Backend (NestJS)
+
+## When to use
+For implementing or extending NestJS services (REST or GraphQL), controllers/resolvers, DTO validation, modules, and integration patterns.
+
+## What to provide
+- Framework version (if relevant)
+- Transport (REST / GraphQL)
+- Auth strategy (JWT, sessions, etc.)
+- DB access layer (Prisma/TypeORM/knex) and conventions
+- Error handling conventions
+- Any existing module structure
+
+## Prompt template
+You are acting as a senior NestJS backend engineer.
+
+Context:
+- Codebase uses NestJS with TypeScript
+- Follow existing module boundaries and naming conventions
+- Prefer DTO validation (class-validator / zod / existing standard)
+- Keep APIs backward compatible unless explicitly instructed
+- Include structured error responses
+
+Task:
+[DESCRIBE THE BACKEND TASK]
+
+Constraints:
+- [LIST CONSTRAINTS: perf, security, no breaking changes, etc.]
+
+Output:
+- Proposed approach (short)
+- Code: modules/controllers/services/DTOs
+- Edge cases and error handling
+- Notes on config/env and migrations if relevant
+
+---
+
+## NestJS Common Pitfalls (enforce these in every task)
+
+### DTOs & Validation
+- **Never use inline TypeScript types on `@Body()`** — `@Body() body: { name?: string }` is erased at runtime. `ValidationPipe({ whitelist: true })` cannot strip/reject fields without class-validator decorators. Always create a DTO class.
+- **`ParseUUIDPipe` on all `:id` params** — `@Param('id', ParseUUIDPipe)` rejects malformed UUIDs as 400 before they reach the DB layer.
+- **`@IsUUID()` on UUID fields in DTOs** — `@IsString()` alone accepts any string; use `@IsUUID()` for FK/reference fields.
+- **`@HttpCode` on every mutating endpoint** — POST → `201`, DELETE/action endpoints → `200`. NestJS defaults POST to 200, which is wrong.
+
+### Module Architecture
+- **Explicit module imports, not `@Global()`** — only infrastructure modules (Prisma, Config) should be `@Global()`. Business modules must declare their dependencies in `imports[]`. Invisible global dependencies break at runtime if `@Global()` is ever removed.
+- **No duplicate class names across modules** — two `CreateTenantDto` with different fields cause silent bugs when imported from the wrong path. Prefix admin variants: `AdminCreateTenantDto`.
+- **No dead code modules** — modules that are never imported in `AppModule` or any other module should be deleted, not left as dead `@Global()` exports.
+
+### State Management
+- **No mutable singleton state in services** — methods like `setApiKey(key)` that mutate `this.apiKey` race under concurrent requests. Pass secrets as parameters instead.
+- **Controller-level Maps need lifecycle cleanup** — if a controller holds Maps (rate limiting, connection tracking), implement `OnModuleDestroy` and clean up entries to prevent memory leaks.
+
+### Response Format
+- **All endpoints return `{ success: true, data }` envelope** — auth token endpoints (login/register) may return flat structure for client compatibility, but all other endpoints must wrap responses.
+
+### Logging
+- **Audit log field names must match JWT payload** — if `JwtStrategy` returns `{ id, tenantId, email }`, use `user?.id` not `user?.userId`. A field name mismatch silently produces `null` in all audit entries.
+- **No PII in log messages** — use generic messages for missing-account scenarios. Log `"password reset for non-existent account"`, not `"password reset for ${email}"`.

package/dist/skills/bug-ticket-creation/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: rivet-bug-ticket-creation
+description: "Creating Jira-ready bug tickets from any source — postmortem action items, debugging findings, monitoring alerts, or ad-"
+---
+
+# Skill: Bug Ticket Creation (Jira)
+
+## When to use
+Creating Jira-ready bug tickets from any source — postmortem action items, debugging findings, monitoring alerts, or ad-hoc discoveries during development.
+
+## Prompt template
+You are acting as an engineer creating a Jira bug ticket.
+
+Input:
+[PASTE POSTMORTEM ACTION ITEMS / DEBUGGING FINDINGS / ALERT DETAILS / BUG DESCRIPTION]
+
+Context:
+- Jira is the system of record
+- Tickets should be actionable and self-contained — another engineer should be able to pick it up without extra context
+- Reference the source (postmortem doc, incident ID, alert name) if available
+
+Task:
+Create one or more Jira-ready bug tickets.
+
+Output per ticket:
+- **Title**: short, specific (e.g., "Fix race condition in token refresh causing 401s under load")
+- **Type**: Bug
+- **Priority**: Critical / High / Medium / Low
+- **Labels**: [postmortem, incident-followup, monitoring, tech-debt, etc.]
+- **Description**:
+  - What happened / what's broken
+  - Root cause (if known)
+  - How it was discovered (postmortem, alert, user report, code review)
+- **Steps to reproduce** (if applicable)
+- **Expected vs actual behavior**
+- **Affected services / components**
+- **Environment**: dev / staging / production
+- **Acceptance criteria**:
+  - [ ] Bug is resolved
+  - [ ] Regression test added
+  - [ ] Monitoring/alert covers this scenario
+- **Linked tickets**: related incident, parent epic, or postmortem doc
+- **Assignee suggestion**: team or area owner based on affected component

package/dist/skills/cloudwatch-troubleshooting/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: rivet-cloudwatch-troubleshooting
+description: "Investigating issues on EC2-hosted services where logs are shipped to CloudWatch — pulling logs, checking instance healt"
+---
+
+# Skill: CloudWatch & EC2 Troubleshooting
+
+## When to use
+Investigating issues on EC2-hosted services where logs are shipped to CloudWatch — pulling logs, checking instance health, and diagnosing application or infrastructure failures.
+
+## Prerequisites
+- AWS CLI installed locally
+- AWS profile configured with access to CloudWatch Logs, EC2, and relevant services
+- Know the log group name(s) for the target service
+
+## Prompt template
+You are acting as an SRE investigating an issue on EC2-hosted services using CloudWatch.
+
+Input:
+[DESCRIBE THE ISSUE: service errors, high latency, instance unreachable, deployment failure, etc.]
+
+Context:
+- AWS profile: [profile name]
+- Region: [e.g., eu-west-1]
+- Log group: [e.g., /app/api-service or /var/log/syslog]
+- EC2 instance ID(s): [if known]
+- Environment: [dev / staging / production]
+
+Task:
+Investigate the issue using AWS CLI.
+
+### Investigation steps
+
+1. **Find the log group and streams**
+   - `aws logs describe-log-groups --profile <profile> --region <region> --log-group-name-prefix <prefix>`
+   - `aws logs describe-log-streams --log-group-name <group> --profile <profile> --region <region> --order-by LastEventTime --descending --limit 10`
+
+2. **Pull recent logs**
+   - `aws logs tail <log-group> --profile <profile> --region <region> --since 30m`
+   - `aws logs tail <log-group> --profile <profile> --region <region> --since 30m --follow` — live tail
+   - `aws logs filter-log-events --log-group-name <group> --filter-pattern "ERROR" --profile <profile> --region <region> --start-time <epoch-ms>` — filter for errors
+
+3. **Check EC2 instance health**
+   - `aws ec2 describe-instance-status --instance-ids <id> --profile <profile> --region <region>`
+   - `aws ec2 describe-instances --instance-ids <id> --profile <profile> --region <region> --query 'Reservations[].Instances[].{State:State.Name,Type:InstanceType,LaunchTime:LaunchTime}'`
+
+4. **Check CloudWatch metrics**
+   - `aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization --dimensions Name=InstanceId,Value=<id> --start-time <ISO> --end-time <ISO> --period 300 --statistics Average --profile <profile> --region <region>`
+   - Key metrics: CPUUtilization, StatusCheckFailed, NetworkIn/Out, DiskReadOps
+
+5. **Check CloudWatch alarms**
+   - `aws cloudwatch describe-alarms --state-value ALARM --profile <profile> --region <region>`
+
+6. **Check system logs (if accessible)**
+   - `aws ec2 get-console-output --instance-id <id> --profile <profile> --region <region>` — boot/kernel logs
+   - Check `/var/log/` log groups if system logs are shipped to CloudWatch
+
+### Common patterns
+- **OOM**: look for "Out of memory" or "Killed process" in system logs, check memory metrics
+- **Disk full**: check DiskSpaceUtilization custom metric or `/var/log/messages`
+- **App crash loop**: filter for repeated startup/shutdown log patterns
+- **Network issues**: check StatusCheckFailed_System, security groups, NACLs
+
+### Output
+- **Status summary**: instance and application health
+- **Root cause**: what the logs and metrics indicate
+- **Fix recommendation**: restart, resize, config change, or code fix
+- **Commands run**: list of commands and key output for the postmortem record
+
+### Related skills
+- For analyzing the root cause after gathering data: see `debugging.md`
+- For writing up the incident afterward: see `incident-postmortem.md`
+- For Kubernetes-based services: see `kubernetes-troubleshooting.md`

package/dist/skills/database-migration/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: rivet-database-migration
+description: "Designing new tables/columns, writing safe migrations, or reviewing schema changes for correctness and backward compatib"
+---
+
+# Skill: Database Migration & Schema Design
+
+## When to use
+
+Designing new tables/columns, writing safe migrations, or reviewing schema changes for correctness and backward compatibility.
+
+## Prompt template
+
+You are acting as a database engineer planning a schema change.
+
+Input:
+[DESCRIBE THE DATA REQUIREMENT OR PASTE EXISTING SCHEMA]
+
+Context:
+
+- Database: [PostgreSQL / MySQL / other]
+- ORM: [Prisma / TypeORM / Django ORM / knex / raw SQL]
+- Environment: changes must be deployable with zero downtime
+- Existing data: [empty table / has production data / approximate row count]
+
+Task:
+Design the schema change and write a safe migration.
+
+Output:
+
+- **Schema design**: tables, columns, types, constraints, indexes
+- **Migration SQL or ORM migration**: forward and rollback
+- **Data migration**: if existing rows need transformation
+- **Deployment strategy**: ordering (migrate before deploy vs after), backfill steps
+- **Zero-downtime notes**: nullable columns first, backfill, then add constraints
+- **Risks**: data loss scenarios, locking concerns on large tables
+- **Validation**: queries to verify migration succeeded
+
+---
+
+## Schema Design Checklist
+
+### Enums vs Strings
+
+Use a PostgreSQL enum (or ORM enum) whenever a column holds a finite, known set of values.
+String columns silently accept typos and invalid values with no DB-level enforcement.
+
+Common candidates to audit: `status`, `plan`, `type`, `decision`, `severity`, `channel`, `invoiceType`, `paymentType`.
+
+Migration pattern (PostgreSQL):
+
+```sql
+CREATE TYPE offer_status AS ENUM ('DRAFT', 'SENT', 'PAID', 'CANCELLED');
+ALTER TABLE offers ALTER COLUMN status TYPE offer_status USING status::text::offer_status;
+```
+
+### Foreign Key Constraints
+
+Every column that references another table's `id` must have an explicit FK constraint with a cascade rule.
+Missing FKs allow orphaned rows to accumulate silently.
+
+- `ON DELETE CASCADE` — child rows deleted when parent is deleted (e.g., refresh tokens when device is deleted)
+- `ON DELETE SET NULL` — nullable FK set to null (e.g., audit log `approvedBy` when user is deleted)
+- `ON DELETE RESTRICT` — default; block deletion if children exist
+
+Before adding a FK to an existing column, clean orphaned rows first:
+
+```sql
+DELETE FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table);
+ALTER TABLE child_table ADD CONSTRAINT fk_parent FOREIGN KEY (parent_id) REFERENCES parent_table(id) ON DELETE CASCADE;
+```
+
+### Composite Unique Constraints
+
+For tenant-scoped uniqueness (e.g., same phone number allowed across tenants, but not within one):
+
+```sql
+ALTER TABLE contacts ADD CONSTRAINT uq_tenant_phone UNIQUE (tenant_id, phone);
+```
+
+PostgreSQL correctly allows multiple `NULL` values in unique constraints, so nullable fields are safe.
+
+### Indexes Checklist
+
+Add indexes for every common query pattern. Missing indexes cause sequential scans as tables grow.
+
+| Query pattern | Index type |
+| ------------- | ---------- |
+| `WHERE tenant_id = ? AND is_enabled = true` | Composite `(tenant_id, is_enabled)` |
+| `WHERE tenant_id = ? AND status = ?` | Composite `(tenant_id, status)` |
+| `WHERE user_id = ?` | Single `(user_id)` |
+| `WHERE expires_at < NOW()` (cleanup jobs) | Single `(expires_at)` |
+| Unique lookup by token | Unique constraint (already creates index — don't add a redundant `@@index`) |
+
+### Redundant Indexes
+
+A `@unique` constraint already creates a B-tree index. Adding an explicit `@@index` on the same column is redundant overhead — remove the duplicate.

package/dist/skills/debugging/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: rivet-debugging
+description: "Investigating production errors, unexpected behavior, or failing tests by systematically narrowing down the root cause f"
+---
+
+# Skill: Debugging & Root Cause Analysis
+
+## When to use
+Investigating production errors, unexpected behavior, or failing tests by systematically narrowing down the root cause from symptoms.
+
+## Prompt template
+You are acting as a senior engineer debugging an issue.
+
+Input:
+[PASTE ERROR LOGS / STACK TRACES / USER REPORT / FAILING TEST OUTPUT]
+
+Context:
+- Service/component affected: [name]
+- Environment: [dev / staging / production]
+- When it started: [timestamp / deployment / change that may have triggered it]
+- What has been tried so far: [any prior investigation]
+
+Task:
+Perform structured root cause analysis.
+
+Output:
+- **Symptom summary**: what is observed
+- **Hypotheses**: ranked list of likely causes (most probable first)
+- **Investigation steps**: specific commands, queries, or checks to confirm each hypothesis
+- **Root cause**: confirmed or best-guess cause with evidence
+- **Fix recommendation**: proposed solution with code or config changes
+- **Prevention**: how to avoid recurrence (tests, alerts, guards)

package/dist/skills/devops-infra/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: rivet-devops-infra
+description: "For Docker, CI/CD, environment separation, monitoring/logging, and deployment procedures."
+---
+
+# Skill: Infrastructure & DevOps
+
+## When to use
+For Docker, CI/CD, environment separation, monitoring/logging, and deployment procedures.
+
+## Prompt template
+You are acting as a DevOps engineer.
+
+Context:
+- Services include NestJS API and React Native build pipeline
+- Environments: dev / stage / prod
+- Follow security best practices (least privilege, secrets management)
+
+Task:
+[DESCRIBE INFRA / PIPELINE NEED]
+
+Output:
+- Proposed config (Docker/CI)
+- Environment variables and secrets handling
+- Rollback strategy
+- Monitoring/logging notes

package/dist/skills/documentation/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: rivet-documentation
+description: "Writing runbooks, architecture notes, onboarding docs, release notes, or decision records."
+---
+
+# Skill: Documentation & Knowledge
+
+## When to use
+Writing runbooks, architecture notes, onboarding docs, release notes, or decision records.
+
+## Prompt template
+You are acting as a technical writer.
+
+Context:
+- Audience: engineers, QA, product, operations
+- Documentation must reflect real behavior and be maintainable
+
+Task:
+[DESCRIBE DOC TO CREATE/UPDATE]
+
+Output:
+- Doc content with clear sections
+- Examples/snippets where useful
+- Links placeholders for related docs

package/dist/skills/frontend-nextjs/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: rivet-frontend-nextjs
+description: "For implementing Next.js frontend pages, components, API integrations, and performance‑optimized UI behavior."
+---
+
+# Skill: Frontend (Next.js)
+
+## When to use
+For implementing Next.js frontend pages, components, API integrations, and performance‑optimized UI behavior.
+
+## Prompt template
+You are acting as a senior Next.js frontend engineer.
+
+Context:
+- Next.js + React + TypeScript
+- Follow existing design system and component patterns
+- Handle loading, error, and empty states properly
+- Ensure API contract alignment with backend
+
+Task:
+[DESCRIBE FRONTEND TASK]
+
+Output:
+- Component or page implementation
+- Types/interfaces
+- Data fetching logic
+- Integration notes