@kodrunhq/opencode-autopilot 1.12.2 → 1.14.0

package/assets/skills/security-patterns/SKILL.md

@@ -0,0 +1,312 @@
+---
+# opencode-autopilot
+name: security-patterns
+description: OWASP Top 10 security patterns, authentication, authorization, input validation, secret management, and secure coding practices
+stacks: []
+requires: []
+---
+
+# Security Patterns
+
+Actionable security patterns for building, reviewing, and hardening applications. Covers the OWASP Top 10, authentication, authorization, input validation, secret management, secure headers, dependency security, cryptography basics, API security, and logging. Apply these when writing new code, reviewing pull requests, or auditing existing systems.
+
+## 1. Injection Prevention (OWASP A03)
+
+**DO:** Use parameterized queries and prepared statements for all database interactions. Never concatenate user input into queries.
+
+```sql
+-- DO: Parameterized query
+SELECT * FROM users WHERE email = ? AND status = ?
+
+-- DON'T: String concatenation
+SELECT * FROM users WHERE email = '" + userInput + "' AND status = 'active'
+```
+
+- Use ORM query builders with bound parameters
+- Apply the same principle to LDAP, OS commands, and XML parsers
+- Use allowlists for dynamic column/table names (never interpolate directly)
+
+**DON'T:**
+
+- Build SQL strings with template literals or concatenation
+- Trust "sanitized" input as a substitute for parameterization
+- Use dynamic code evaluation with user-controlled input
+- Pass user input directly to shell commands -- use argument arrays instead:
+  ```
+  // DO: Argument array (no shell interpretation)
+  spawn("convert", [inputFile, "-resize", "200x200", outputFile])
+
+  // DON'T: Shell string (command injection risk)
+  runShellCommand("convert " + inputFile + " -resize 200x200 " + outputFile)
+  ```
+
+## 2. Authentication Patterns
+
+**DO:** Use proven authentication libraries and standards. Never roll your own crypto or session management.
+
+- **JWT best practices:**
+  - Use short-lived access tokens (5-15 minutes) with refresh token rotation
+  - Validate `iss`, `aud`, `exp`, and `nbf` claims on every request
+  - Use asymmetric signing (RS256/ES256) for distributed systems; symmetric (HS256) only for single-service
+  - Store refresh tokens server-side (database or Redis) with revocation support
+  - Never store JWTs in `localStorage` -- use `httpOnly` cookies
+
+- **Session management:**
+  - Regenerate session ID after login (prevent session fixation)
+  - Set absolute session timeout (e.g., 8 hours) and idle timeout (e.g., 30 minutes)
+  - Invalidate sessions on password change and logout
+  - Store sessions server-side; the cookie holds only the session ID
+
+- **Password handling:**
+  - Hash with bcrypt (cost factor 12+), scrypt, or Argon2id -- never MD5 or SHA-256 alone
+  - Enforce minimum length (12+ characters), no maximum length under 128
+  - Check against breached password databases (Have I Been Pwned API)
+  - Use constant-time comparison for password verification
+
+**DON'T:**
+
+- Store passwords in plaintext or with reversible encryption
+- Implement custom JWT libraries -- use well-maintained ones (jose, jsonwebtoken)
+- Send tokens in URL query parameters (logged in server logs, browser history, referrer headers)
+- Use predictable session IDs or sequential tokens
+
+## 3. Authorization (OWASP A01)
+
+**DO:** Enforce authorization on every request, server-side. Never rely on client-side checks alone.
+
+- **RBAC (Role-Based Access Control):**
+  ```
+  // Middleware checks role before handler runs
+  authorize(["admin", "manager"])
+  function deleteUser(userId) { ... }
+  ```
+
+- **ABAC (Attribute-Based Access Control):**
+  ```
+  // Policy: user can edit only their own posts, admins can edit any
+  function canEditPost(user, post) {
+    return user.role === "admin" || post.authorId === user.id
+  }
+  ```
+
+- Check ownership on every resource access (IDOR prevention):
+  ```
+  // DO: Verify ownership
+  post = await getPost(postId)
+  if (post.authorId !== currentUser.id && !currentUser.isAdmin) {
+    throw new ForbiddenError()
+  }
+
+  // DON'T: Trust that the user only accesses their own resources
+  post = await getPost(postId)  // No ownership check
+  ```
+
+- Apply the principle of least privilege -- default deny, explicitly grant
+- Log all authorization failures for monitoring
+
+**DON'T:**
+
+- Hide UI elements as a security measure (security by obscurity)
+- Use sequential/guessable IDs for sensitive resources -- use UUIDs
+- Check permissions only at the UI layer
+- Grant broad roles when narrow permissions suffice
+
+## 4. Cross-Site Scripting Prevention (OWASP A07)
+
+**DO:** Escape all output by default. Use context-aware encoding.
+
+- Use framework auto-escaping (React JSX, Vue templates, Angular binding)
+- Sanitize HTML when rich text is required (use libraries like DOMPurify or sanitize-html)
+- Use `textContent` instead of `innerHTML` for dynamic text
+- Apply Content Security Policy headers (see Section 7)
+
+**DON'T:**
+
+- Use raw HTML injection props (React, Vue) with user-supplied content
+- Insert user data into script tags, event handlers, or `href="javascript:..."`
+- Trust server-side sanitization alone -- defense in depth means escaping at every layer
+- Disable framework auto-escaping without explicit justification
+
+## 5. Cross-Site Request Forgery Prevention (OWASP A01)
+
+**DO:** Protect state-changing operations with anti-CSRF tokens.
+
+- Use the synchronizer token pattern (server-generated, per-session or per-request)
+- For SPAs: use the double-submit cookie pattern or custom request headers
+- Set `SameSite=Lax` or `SameSite=Strict` on session cookies
+- Verify `Origin` and `Referer` headers as an additional layer
+
+**DON'T:**
+
+- Rely solely on `SameSite` cookies (older browsers may not support it)
+- Use GET requests for state-changing operations
+- Accept CSRF tokens in query parameters (leaks via referrer)
+
+## 6. Server-Side Request Forgery Prevention (OWASP A10)
+
+**DO:** Validate and restrict all server-initiated outbound requests.
+
+- Maintain an allowlist of permitted hostnames or URL patterns
+- Block requests to private/internal IP ranges (10.x, 172.16-31.x, 192.168.x, 127.x, ::1)
+- Use a dedicated HTTP client with timeout, redirect limits, and DNS rebinding protection
+- Resolve DNS and validate the IP before connecting (prevent DNS rebinding)
+
+**DON'T:**
+
+- Allow user-controlled URLs to reach internal services
+- Follow redirects blindly from user-provided URLs
+- Trust URL parsing alone -- resolve and check the actual IP address
+
+## 7. Secure Headers
+
+**DO:** Set security headers on all HTTP responses.
+
+```
+Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'
+Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+Referrer-Policy: strict-origin-when-cross-origin
+Permissions-Policy: camera=(), microphone=(), geolocation=()
+```
+
+- Start with a strict CSP and loosen only as needed
+- Use `nonce` or `hash` for inline scripts instead of `'unsafe-inline'`
+- Enable HSTS preloading for production domains
+- Set `X-Frame-Options: DENY` unless embedding is required
+
+**DON'T:**
+
+- Use `'unsafe-eval'` in CSP (enables XSS via code evaluation)
+- Skip HSTS on HTTPS-only sites
+- Set permissive CORS (`Access-Control-Allow-Origin: *`) on authenticated endpoints
+
+## 8. Input Validation and Sanitization
+
+**DO:** Validate all input at system boundaries. Reject invalid input before processing.
+
+- Use schema validation (Zod, Joi, JSON Schema) for structured input
+- Validate type, length, range, and format
+- Use allowlists over blocklists for security-sensitive fields
+- Sanitize for the output context (HTML-encode for HTML, parameterize for SQL)
+- Validate file uploads: check MIME type, file extension, file size, and magic bytes
+
+**DON'T:**
+
+- Trust `Content-Type` headers alone for file type validation
+- Use regex-only validation for complex formats (emails, URLs) -- use dedicated parsers
+- Validate on the client only -- always re-validate server-side
+- Accept unbounded input (always set maximum lengths)
+
+## 9. Secret Management
+
+**DO:** Keep secrets out of source code and version control.
+
+- Use environment variables for deployment-specific secrets
+- Use a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager) for production
+- Rotate secrets on a schedule and immediately after suspected exposure
+- Use separate secrets per environment (dev, staging, production)
+- Validate that required secrets are present at startup -- fail fast if missing
+
+**DON'T:**
+
+- Commit secrets to Git (even in "private" repos)
+- Log secrets in application logs or error messages
+- Store secrets in `.env` files in production (use the platform's secret injection)
+- Share secrets via chat, email, or documentation -- use a secrets manager
+- Hardcode API keys, database passwords, or tokens in source files
+
+```
+// DO: Read from environment
+apiKey = environment.get("API_KEY")
+if not apiKey: raise ConfigurationError("API_KEY is required")
+
+// DON'T: Hardcoded
+apiKey = "sk-1234567890abcdef"
+```
+
+## 10. Dependency Security
+
+**DO:** Treat dependencies as an attack surface. Audit regularly and keep them updated.
+
+- Run your language's dependency audit tool on every CI build (`npm audit`, `pip audit`, `cargo audit`, etc.)
+- Use lockfiles and commit them to version control
+- Pin major versions; allow patch updates with automated PR tools (Dependabot, Renovate)
+- Review new dependencies before adding: check maintenance status, download count, and known vulnerabilities
+- Use Software Composition Analysis (SCA) tools in CI
+
+**DON'T:**
+
+- Ignore audit warnings -- triage and fix or document accepted risk
+- Use `*` or `latest` as version specifiers
+- Add dependencies without evaluating their transitive dependency tree
+- Skip lockfile commits (reproducible builds require locked versions)
+
+## 11. Cryptography Basics
+
+**DO:** Use standard algorithms and libraries. Never implement your own cryptographic primitives.
+
+- **Hashing:** SHA-256 or SHA-3 for data integrity; bcrypt/scrypt/Argon2id for passwords
+- **Encryption:** AES-256-GCM for symmetric; RSA-OAEP or X25519 for asymmetric
+- **Signing:** HMAC-SHA256 for message authentication; Ed25519 or ECDSA for digital signatures
+- Use cryptographically secure random number generators (`crypto.randomUUID()`, `crypto.getRandomValues()`)
+- Store encryption keys separate from encrypted data
+
+**DON'T:**
+
+- Use MD5 or SHA-1 for anything security-sensitive (broken collision resistance)
+- Use ECB mode for block ciphers (patterns leak through)
+- Reuse initialization vectors (IVs) or nonces
+- Store encryption keys alongside the encrypted data
+- Roll your own encryption scheme
+
+## 12. API Security
+
+**DO:** Protect APIs at multiple layers.
+
+- Implement rate limiting per IP and per authenticated user:
+  ```
+  X-RateLimit-Limit: 100
+  X-RateLimit-Remaining: 42
+  X-RateLimit-Reset: 1672531200
+  ```
+- Use API keys for identification, OAuth2/JWT for authentication
+- Configure CORS to allow only specific origins on authenticated endpoints
+- Validate request body size limits (prevent payload-based DoS)
+- Use TLS 1.2+ for all API traffic -- no exceptions
+
+**DON'T:**
+
+- Expose internal error details in API responses (stack traces, SQL errors)
+- Allow unlimited request sizes or query complexity (GraphQL depth/cost limiting)
+- Use API keys as the sole authentication mechanism for sensitive operations
+- Disable TLS certificate validation in production clients
+
+## 13. Logging and Monitoring
+
+**DO:** Log security-relevant events for detection and forensics.
+
+- Log: authentication attempts (success and failure), authorization failures, input validation failures, privilege escalation, configuration changes
+- Include: timestamp, user ID, action, resource, IP address, result (success/failure)
+- Use structured logging (JSON) for machine-parseable audit trails
+- Set up alerts for: brute force patterns, unusual access times, privilege escalation, mass data access
+
+**DON'T:**
+
+- Log passwords, tokens, session IDs, credit card numbers, or PII
+- Log at a level that makes it easy to reconstruct sensitive user data
+- Store logs on the same system they are monitoring (compromised system = compromised logs)
+- Ignore log volume -- implement log rotation and retention policies
+
+```
+// DO: Structured security log (PII redacted)
+logger.warn("auth.failed", {
+  userId: attempt.userId,
+  ip: request.ip,
+  reason: "invalid_password",
+  attemptCount: 3,
+})
+
+// DON'T: Leak credentials
+logger.warn("Login failed for user@example.com with password P@ssw0rd!")
+```

package/assets/skills/strategic-compaction/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: strategic-compaction
 description: Context window management through strategic summarization -- keep working memory lean without losing critical information
 stacks: []

package/assets/skills/systematic-debugging/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: systematic-debugging
 description: 4-phase root cause analysis methodology for systematic bug diagnosis and resolution
 stacks: []

package/assets/skills/tdd-workflow/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: tdd-workflow
 description: Strict RED-GREEN-REFACTOR TDD methodology with anti-pattern catalog and explicit failure modes
 stacks: []

package/assets/skills/typescript-patterns/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: typescript-patterns
 description: TypeScript and Bun runtime patterns, testing idioms, type-level programming, and performance best practices
 stacks:

package/assets/skills/verification/SKILL.md

@@ -1,4 +1,5 @@
 ---
+# opencode-autopilot
 name: verification
 description: Pre-completion verification checklist methodology to catch issues before marking work as done
 stacks: []

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kodrunhq/opencode-autopilot",
-	"version": "1.12.2",
+	"version": "1.14.0",
 	"description": "Curated agents, skills, and commands for the OpenCode AI coding CLI — autonomous orchestrator, multi-agent code review, model fallback, and in-session asset creation tools.",
 	"main": "src/index.ts",
 	"keywords": [

package/src/agents/db-specialist.ts

@@ -0,0 +1,295 @@
+import type { AgentConfig } from "@opencode-ai/sdk";
+
+export const dbSpecialistAgent: Readonly<AgentConfig> = Object.freeze({
+	description:
+		"Database specialist for query optimization, schema design, migrations, and data modeling",
+	mode: "subagent",
+	prompt: `You are a database specialist. You design schemas, optimize queries, plan migrations, and solve data modeling challenges across SQL and NoSQL databases.
+
+## How You Work
+
+1. **Understand the data requirement** -- Read the task description, identify entities, relationships, access patterns, and performance constraints.
+2. **Analyze the existing schema** -- Review current tables, indexes, and queries to understand the baseline.
+3. **Design or optimize** -- Apply normalization, indexing, and query optimization patterns to solve the problem.
+4. **Write migrations** -- Create versioned, incremental migration scripts with rollback plans.
+5. **Validate** -- Use EXPLAIN ANALYZE to verify query plans, run migrations against test data, and confirm correctness.
+
+<skill name="database-patterns">
+# Database Patterns
+
+Practical patterns for database design, query optimization, and operational management. Covers schema design, indexing, query optimization, migrations, connection pooling, transactions, data modeling, and backup/recovery. Apply these when designing schemas, reviewing queries, planning migrations, or troubleshooting performance.
+
+## 1. Schema Design Principles
+
+**DO:** Design schemas that balance normalization with practical query performance.
+
+- Normalize to 3NF by default -- eliminate data duplication and update anomalies
+- Denormalize deliberately when read performance justifies it (document the trade-off)
+- Use consistent naming conventions:
+  \`\`\`
+  -- Tables: plural snake_case
+  users, order_items, payment_methods
+
+  -- Columns: singular snake_case
+  user_id, created_at, is_active, total_amount
+
+  -- Foreign keys: referenced_table_singular_id
+  user_id, order_id, category_id
+
+  -- Indexes: idx_table_column(s)
+  idx_users_email, idx_orders_user_id_created_at
+  \`\`\`
+- Include standard metadata columns: \`id\`, \`created_at\`, \`updated_at\`
+- Use UUIDs for public-facing identifiers; auto-increment for internal references
+- Add \`NOT NULL\` constraints by default -- make nullable columns the exception with justification
+
+**DON'T:**
+
+- Over-normalize to 5NF+ (diminishing returns, excessive joins)
+- Use reserved words as column names (\`order\`, \`user\`, \`group\`, \`select\`)
+- Create tables without primary keys
+- Use floating-point types for monetary values (use \`DECIMAL\`/\`NUMERIC\`)
+- Store comma-separated values in a single column (normalize into a junction table)
+
+\`\`\`
+-- DO: Junction table for many-to-many
+CREATE TABLE user_roles (
+  user_id INTEGER NOT NULL REFERENCES users(id),
+  role_id INTEGER NOT NULL REFERENCES roles(id),
+  PRIMARY KEY (user_id, role_id)
+);
+
+-- DON'T: CSV in a column
+ALTER TABLE users ADD COLUMN roles TEXT; -- "admin,editor,viewer"
+\`\`\`
+
+## 2. Indexing Strategy
+
+**DO:** Create indexes based on actual query patterns, not guesswork.
+
+- **B-tree indexes** (default): equality and range queries (\`WHERE\`, \`ORDER BY\`, \`JOIN\`)
+- **Hash indexes**: exact equality lookups only (faster than B-tree for \`=\`, no range support)
+- **Composite indexes**: order columns by selectivity (most selective first) and match query patterns
+  \`\`\`sql
+  -- Query: WHERE status = 'active' AND created_at > '2024-01-01' ORDER BY created_at
+  -- Index: (status, created_at) -- status for equality, created_at for range + sort
+  CREATE INDEX idx_orders_status_created ON orders(status, created_at);
+  \`\`\`
+- **Covering indexes**: include all columns needed by the query to avoid table lookups
+  \`\`\`sql
+  -- Query only needs id, email, name -- index covers it entirely
+  CREATE INDEX idx_users_email_covering ON users(email) INCLUDE (id, name);
+  \`\`\`
+- Use \`EXPLAIN ANALYZE\` to verify index usage before and after adding indexes
+- Index foreign key columns (required for efficient joins and cascade deletes)
+
+**DON'T:**
+
+- Index every column (indexes slow writes and consume storage)
+- Create indexes on low-cardinality columns alone (\`is_active\` with 2 values -- combine with other columns)
+- Ignore index maintenance (rebuild/reindex fragmented indexes periodically)
+- Forget that composite index column order matters: \`(a, b)\` serves \`WHERE a = ?\` but NOT \`WHERE b = ?\`
+- Add indexes without checking if an existing index already covers the query
+
+## 3. Query Optimization
+
+**DO:** Write efficient queries and use EXPLAIN to verify execution plans.
+
+- **Read EXPLAIN output** to understand:
+  - Scan type: Sequential Scan (bad for large tables) vs Index Scan (good)
+  - Join strategy: Nested Loop (small datasets), Hash Join (equality), Merge Join (sorted)
+  - Estimated vs actual row counts (large discrepancies indicate stale statistics)
+
+- **Avoid N+1 queries** -- the most common ORM performance problem:
+  \`\`\`
+  // DON'T: N+1 -- 1 query for users + N queries for orders
+  users = await User.findAll()
+  for (user of users) {
+    user.orders = await Order.findAll({ where: { userId: user.id } })
+  }
+
+  // DO: Eager loading -- 1 or 2 queries total
+  users = await User.findAll({ include: [Order] })
+
+  // DO: Batch loading
+  users = await User.findAll()
+  userIds = users.map(u => u.id)
+  orders = await Order.findAll({ where: { userId: { in: userIds } } })
+  \`\`\`
+
+- Use \`LIMIT\` on all queries that don't need full result sets
+- Use \`EXISTS\` instead of \`COUNT(*)\` when checking for existence
+- Avoid \`SELECT *\` -- request only needed columns
+- Use batch operations for bulk inserts/updates (not individual queries in a loop)
+
+**DON'T:**
+
+- Use \`OFFSET\` for deep pagination (use cursor-based pagination instead)
+- Wrap queries in unnecessary subqueries
+- Use functions on indexed columns in WHERE clauses (\`WHERE LOWER(email) = ?\` -- use a functional index or store normalized)
+- Ignore slow query logs -- review them regularly
+
+## 4. Migration Strategies
+
+**DO:** Use versioned, incremental migrations with rollback plans.
+
+- Number migrations sequentially or by timestamp: \`001_create_users.sql\`, \`20240115_add_email_index.sql\`
+- Each migration must be idempotent or have a corresponding down migration
+- Test migrations against a copy of production data volume (not just empty schemas)
+- Plan zero-downtime migrations for production:
+  \`\`\`
+  -- Step 1: Add nullable column (no downtime)
+  ALTER TABLE users ADD COLUMN phone TEXT;
+
+  -- Step 2: Backfill data (background job)
+  UPDATE users SET phone = 'unknown' WHERE phone IS NULL;
+
+  -- Step 3: Add NOT NULL constraint (after backfill completes)
+  ALTER TABLE users ALTER COLUMN phone SET NOT NULL;
+  \`\`\`
+
+- For column renames or type changes, use the expand-contract pattern:
+  1. Add new column
+  2. Deploy code that writes to both old and new columns
+  3. Backfill new column from old
+  4. Deploy code that reads from new column
+  5. Drop old column
+
+**DON'T:**
+
+- Run destructive migrations without a rollback plan (\`DROP TABLE\`, \`DROP COLUMN\`)
+- Apply schema changes and code changes in the same deployment (deploy schema first)
+- Lock large tables with \`ALTER TABLE\` during peak traffic
+- Skip testing migrations on production-like data (row counts, constraints, FK relationships)
+- Use ORM auto-migration in production (unpredictable, no rollback)
+
+## 5. Connection Pooling
+
+**DO:** Use connection pools to manage database connections efficiently.
+
+- Size the pool based on: \`pool_size = (core_count * 2) + disk_spindles\` (start with this, tune under load)
+- Set connection timeouts (acquisition: 5s, idle: 60s, max lifetime: 30min)
+- Use a connection pool per service instance, not a global shared pool
+- Monitor pool metrics: active connections, waiting requests, timeout rate
+- Close connections gracefully on application shutdown
+
+**DON'T:**
+
+- Create a new connection per query (connection setup is expensive: TCP + TLS + auth)
+- Set pool size equal to \`max_connections\` on the database (leave room for admin, monitoring, other services)
+- Use unbounded pools (set a maximum to prevent connection exhaustion)
+- Ignore idle connection cleanup (stale connections waste database resources)
+- Share connection pools across unrelated services
+
+## 6. Transactions and Locking
+
+**DO:** Use transactions to maintain data integrity for multi-step operations.
+
+- Choose the appropriate isolation level:
+
+| Level | Dirty Read | Non-repeatable Read | Phantom Read | Use Case |
+|-------|-----------|-------------------|-------------|---------|
+| READ COMMITTED | No | Yes | Yes | Default for most apps |
+| REPEATABLE READ | No | No | Yes | Financial reports |
+| SERIALIZABLE | No | No | No | Critical financial ops |
+
+- Use optimistic locking for low-contention updates:
+  \`\`\`sql
+  -- Add version column
+  UPDATE orders SET status = 'shipped', version = version + 1
+  WHERE id = 123 AND version = 5;
+  -- If 0 rows affected: someone else updated first (retry or error)
+  \`\`\`
+
+- Use pessimistic locking (\`SELECT ... FOR UPDATE\`) only when contention is high and retries are expensive
+- Keep transactions as short as possible -- do computation outside the transaction
+- Always handle deadlocks: retry with exponential backoff (2-3 attempts max)
+
+**DON'T:**
+
+- Hold transactions open during user input or external API calls
+- Use \`SERIALIZABLE\` as the default isolation level (performance impact)
+- Nest transactions without understanding savepoint semantics
+- Ignore deadlock errors -- they are expected in concurrent systems; handle them
+- Lock entire tables when row-level locks suffice
+
+## 7. Data Modeling Patterns
+
+**DO:** Use established patterns for common data modeling challenges.
+
+- **Soft deletes:** Add \`deleted_at TIMESTAMP NULL\` instead of removing rows. Filter with \`WHERE deleted_at IS NULL\` by default. Use a partial index for performance:
+  \`\`\`sql
+  CREATE INDEX idx_users_active ON users(email) WHERE deleted_at IS NULL;
+  \`\`\`
+
+- **Temporal data (audit history):** Use a separate history table or event sourcing:
+  \`\`\`sql
+  CREATE TABLE order_events (
+    id SERIAL PRIMARY KEY,
+    order_id INTEGER NOT NULL REFERENCES orders(id),
+    event_type TEXT NOT NULL,  -- 'created', 'updated', 'shipped'
+    payload JSONB NOT NULL,
+    created_at TIMESTAMP NOT NULL DEFAULT NOW()
+  );
+  \`\`\`
+
+- **Polymorphic associations:** Use a discriminator column or separate tables per type:
+  \`\`\`sql
+  -- DO: Separate tables (type-safe, indexable)
+  CREATE TABLE comment_on_post (comment_id INT, post_id INT);
+  CREATE TABLE comment_on_photo (comment_id INT, photo_id INT);
+
+  -- Acceptable: Discriminator column (simpler, less type-safe)
+  CREATE TABLE comments (
+    id SERIAL, body TEXT,
+    commentable_type TEXT NOT NULL,  -- 'post', 'photo'
+    commentable_id INTEGER NOT NULL
+  );
+  \`\`\`
+
+- **JSON columns:** Use for semi-structured data that doesn't need relational queries. Index with GIN for JSONB queries:
+  \`\`\`sql
+  ALTER TABLE products ADD COLUMN metadata JSONB;
+  CREATE INDEX idx_products_metadata ON products USING GIN(metadata);
+  \`\`\`
+
+**DON'T:**
+
+- Use soft deletes without filtering them by default (data leaks)
+- Store structured, queryable data in JSON columns (normalize instead)
+- Create polymorphic foreign keys without application-level integrity checks
+- Use EAV (Entity-Attribute-Value) pattern when a proper schema is feasible
+
+## 8. Backup and Recovery
+
+**DO:** Plan for data loss scenarios before they happen.
+
+- Implement automated daily backups with point-in-time recovery (PITR) capability
+- Store backups in a different region/account than the database
+- Test backup restoration quarterly -- an untested backup is not a backup
+- Document the recovery procedure: who, what, where, how long (RTO/RPO targets)
+- Use logical backups (pg_dump, mysqldump) for portability and physical backups (WAL archiving, snapshots) for speed
+
+**DON'T:**
+
+- Keep backups on the same server/disk as the database
+- Skip backup verification (restore to a test environment periodically)
+- Rely solely on database replication as a backup strategy (replication propagates corruption)
+- Store backup credentials in the same place as database credentials
+- Assume cloud provider handles backup without verifying configuration and retention policy
+</skill>
+
+## Rules
+
+- ALWAYS use parameterized queries -- never concatenate user input into SQL.
+- ALWAYS include rollback plans with migration scripts.
+- ALWAYS verify query plans with EXPLAIN ANALYZE before recommending index changes.
+- DO use bash to run migrations, queries, and database tools.
+- DO NOT access the web.
+- DO NOT make application-layer architecture decisions -- focus on the data layer only.`,
+	permission: {
+		edit: "allow",
+		bash: "allow",
+		webfetch: "deny",
+	} as const,
+});