@kennethsolomon/shipkit 1.0.0

package/skills/sk:review/SKILL.md

@@ -0,0 +1,346 @@
+---
+name: sk:review
+description: "Rigorous self-review of all branch changes across 7 dimensions: correctness, security, performance, reliability, design quality, best practices, and testing. Report-only — no PR creation (that's /sk:finish-feature's job). Use when code is complete and ready for review before merging."
+---
+
+# Self-Review
+
+## Overview
+
+Perform a rigorous, multi-dimensional review of all changes on the current branch. This review aims for the quality bar of a senior engineer at a top-tier tech company — thorough, specific, and honest.
+
+**You are the reviewer, not the cheerleader.** Your job is to find problems, not to praise the code. If you find nothing wrong, look harder. Real code almost always has something worth flagging. Think about what could go wrong in production at scale, under adversarial conditions, and over time as the codebase evolves.
+
+This is a **report-only** step. If Critical or Warning issues are found, the user loops back to `/sk:debug` → `/sk:smart-commit` → `/sk:review` until the branch is clean. Once clean, the user runs `/sk:finish-feature` to finalize and create the PR.
+
+## Allowed Tools
+
+Bash, Read, Glob, Grep
+
+**Intentionally NO Write or Edit** — this skill is report-only. If issues are found, the user decides what to fix.
+
+## Steps
+
+You MUST complete these steps in order:
+
+### 1. Read Project Context
+
+```
+CLAUDE.md                  — Coding standards, conventions, known patterns
+tasks/lessons.md           — Recurrent bug patterns for this project (if exists)
+tasks/security-findings.md — Prior security audit results (if exists)
+```
+
+Understand what "correct" looks like for this project — the tech stack, conventions, and known pitfalls.
+
+If `tasks/lessons.md` exists, read it in full. Use each active lesson's **Bug** field
+as an additional targeted check during analysis — treat each lesson as a known failure
+mode to explicitly scan for across all review dimensions.
+
+If `tasks/security-findings.md` exists, read the most recent audit. Use any unresolved
+Critical/High findings as additional targeted checks — verify the current diff doesn't
+reintroduce previously flagged vulnerabilities.
+
+### 2. Collect All Changes
+
+```bash
+# Determine base branch
+git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main"
+
+# All changes on this branch
+git diff main..HEAD
+git diff main..HEAD --stat
+git log main..HEAD --oneline
+
+# Check for uncommitted changes
+git status --short
+```
+
+If there are uncommitted changes, warn:
+> **Warning:** You have uncommitted changes. These will NOT be included in the review. Commit or stash them first.
+
+Read the full content of every changed file (not just the diff hunks) to understand context around the changes.
+
+### 3. Analyze — Correctness & Bugs
+
+The most important dimension. A bug that ships is worse than ugly code that works.
+
+**Logic errors:**
+- Wrong operator (`&&` vs `||`, `==` vs `===`, `<` vs `<=`)
+- Inverted conditions, missing negation
+- Missing `break`/`return`/`continue` in control flow
+- Off-by-one errors in loops, array indexing, string slicing, pagination
+
+**Null/undefined safety:**
+- Missing null checks before property access
+- Optional chaining needed but not used
+- Nullable values passed where non-null expected
+- Array/object destructuring on potentially undefined values
+
+**Async correctness:**
+- Missing `await` on async calls (floating promises)
+- Unhandled promise rejections
+- Race conditions from shared state mutation across async boundaries
+- Async operations in loops without proper batching (`Promise.all` vs sequential)
+
+**Data integrity:**
+- Partial updates without transactions (DB operations that should be atomic)
+- Missing rollback on error in multi-step operations
+- Stale closures capturing outdated state
+- Cache invalidation gaps (data updated but cache not cleared)
+
+**Edge cases:**
+- Empty arrays/strings/objects not handled
+- Negative numbers, zero, MAX_INT boundaries
+- Unicode/special characters in user input
+- Concurrent access to shared resources
+
+### 4. Analyze — Security
+
+Load `references/security-checklist.md` and apply its grep patterns systematically. Check for:
+
+**Injection (OWASP A03):**
+- SQL, NoSQL, OS command, LDAP, template injection
+- String concatenation/interpolation in queries instead of parameterized queries
+- `eval()`, `exec()`, `Function()` with any dynamic input
+
+**Cross-Site Scripting (OWASP A03):**
+- `dangerouslySetInnerHTML`, `innerHTML`, `v-html` without sanitization
+- URL parameters reflected without encoding
+- User content rendered in `href`, `src`, or event handler attributes
+
+**Authentication & Authorization (OWASP A01, A07):**
+- Hardcoded secrets, API keys, tokens in source code
+- Missing auth checks on endpoints (especially admin, destructive operations)
+- IDOR — user-controlled IDs accessing other users' resources without ownership verification
+- Weak session management, missing token rotation
+
+**Data exposure (OWASP A02):**
+- Credentials, PII, or tokens in logs
+- Stack traces or internal errors leaked to clients
+- Sensitive data in client-side bundles (secret keys in frontend code)
+- Missing encryption for sensitive data at rest
+
+**Configuration (OWASP A05):**
+- Missing security headers (CSP, HSTS, X-Frame-Options)
+- Overly permissive CORS (`origin: '*'`)
+- Debug mode enabled in production paths
+- Missing rate limiting on auth/sensitive endpoints
+
+### 5. Analyze — Performance
+
+Think about what happens at 10x, 100x current scale. Performance bugs are often invisible in development but catastrophic in production.
+
+**Database & queries:**
+- N+1 query patterns (fetching related data in a loop instead of a join or batch)
+- Missing database indexes for frequently queried columns
+- `SELECT *` when only specific columns are needed
+- Unbounded queries without `LIMIT`/pagination
+- Missing connection pooling or pool exhaustion risks
+
+**Algorithm & data structures:**
+- O(n²) or worse in hot paths (nested loops over large collections)
+- Repeated expensive computations that should be memoized
+- Large data structures held in memory unnecessarily
+- String concatenation in tight loops (use array join/builder)
+
+**Frontend performance (React/Next.js):**
+- Unnecessary re-renders (missing `React.memo`, `useMemo`, `useCallback` where beneficial)
+- Large bundle imports (importing entire library when only one function needed)
+- Missing code splitting for heavy routes/components
+- Images without lazy loading or size optimization
+- Blocking operations on the main thread
+
+**Network & I/O:**
+- Sequential API calls that could be parallelized
+- Missing request timeouts on external service calls
+- Large payloads without compression or pagination
+- Missing caching headers for static/rarely-changing resources
+
+**Memory:**
+- Event listeners added but never removed (memory leaks)
+- Growing arrays/maps without bounds or cleanup
+- Large file processing without streaming
+- Closures capturing large scopes unnecessarily
+
+### 6. Analyze — Reliability & Error Handling
+
+Production code must handle failure gracefully. The question isn't "does it work?" but "what happens when things go wrong?"
+
+**Error handling quality:**
+- Swallowed errors (empty catch blocks, `.catch(() => {})`)
+- Generic catch blocks that hide the actual error type
+- Missing error messages that would help debugging
+- Errors caught but not logged or reported
+- Cleanup logic missing in error paths (connections, file handles, locks)
+
+**Graceful degradation:**
+- What happens when an external service is down? Does the whole feature break?
+- Missing fallback behavior for optional dependencies
+- Timeout handling on external calls (HTTP, database, third-party APIs)
+- Missing retry logic with backoff for transient failures
+
+**Data validation at boundaries:**
+- API inputs not validated before processing
+- Missing type/schema validation on external data (webhooks, API responses)
+- File uploads without type/size validation
+- Trusting client-side validation without server-side checks
+
+**State management:**
+- Inconsistent error states (loading indicator stays forever on error)
+- Missing loading/error/empty states in UI
+- Optimistic updates without rollback on failure
+
+### 7. Analyze — Design & Best Practices
+
+Think about the next engineer who reads this code. Is the intent clear? Does the design scale with the codebase?
+
+**Separation of concerns:**
+- Business logic mixed with presentation/routing/data access
+- Components doing too many things (should be split)
+- Side effects in pure functions or constructors
+
+**API design (if endpoints changed):**
+- Breaking changes to existing API contracts without versioning
+- Inconsistent response format across endpoints
+- Missing or inconsistent HTTP status codes
+- Unclear or missing error response schema
+
+**Code clarity:**
+- Naming — are names descriptive and consistent with project conventions?
+- Dead code — commented-out code, unused imports, unreachable branches
+- DRY violations — copy-pasted logic that should be extracted
+- Function length — functions over ~50 lines that should be split
+- Deeply nested logic (>3 levels) that should be flattened with early returns
+
+**Dependency management:**
+- New dependencies added — are they necessary? Well-maintained? License-compatible?
+- Are there lighter alternatives for heavy imports?
+- Lock file updated when dependencies change?
+
+### 8. Analyze — Framework-Specific
+
+Based on what the project uses:
+
+**React/Next.js:**
+- Missing keys in list rendering (or using array index as key for dynamic lists)
+- `useEffect` dependency arrays — missing deps cause stale data, unnecessary deps cause infinite loops
+- Client vs server component boundaries (Next.js App Router) — using hooks in server components, importing server-only code in client
+- State updates on unmounted components
+- Missing `Suspense` boundaries for async components
+- Missing `ErrorBoundary` for component-level error isolation
+
+**Python:**
+- Missing type hints on public functions and API endpoints
+- Mutable default arguments (`def f(items=[])`)
+- Bare `except:` clauses (should catch specific exceptions)
+- Async context managers not used (`async with` for DB connections)
+- Missing `__all__` exports in public modules
+
+**Go:**
+- Unchecked error returns (especially on `Close()`, `Write()`, `Flush()`)
+- Deferred function errors ignored (`defer f.Close()` without checking error)
+- Goroutine leaks (goroutines started without cancellation context)
+- Missing mutex for concurrent access to shared state
+- Context not propagated through call chain
+
+**Node.js/Express:**
+- Missing error-handling middleware
+- Unhandled promise rejections in route handlers
+- Missing `helmet` or equivalent security headers
+- `req.body` used without validation middleware
+
+**General:**
+- Environment-specific code without feature flags or env checks
+- Missing input validation at system boundaries
+- Inconsistent error response format across endpoints
+- Magic numbers/strings that should be named constants
+
+### 9. Analyze — Testing (if tests are included in the diff)
+
+If the diff includes test files, review them with the same rigor as production code.
+
+- **Coverage gaps:** Are all new code paths exercised? Happy path AND error paths?
+- **Edge cases:** Do tests cover boundary conditions, empty inputs, invalid data?
+- **Test isolation:** Do tests depend on external state, order, or other tests?
+- **Assertion quality:** Are assertions specific enough to catch regressions? (not just `toBeTruthy`)
+- **Test naming:** Do test names describe the behavior being verified?
+- **Mocking:** Are mocks minimal and realistic? Over-mocking hides real bugs.
+- **Flakiness risks:** Timing-dependent assertions, network calls, random data without seeding
+
+### 10. Generate Review Report
+
+Format findings with severity levels and review dimensions:
+
+```markdown
+## Code Review: [branch-name]
+
+**Changes:** X files changed, +Y/-Z lines
+**Commits:** N commits
+**Review dimensions:** Correctness, Security, Performance, Reliability, Design, Best Practices, Testing
+
+### Critical (must fix before merge)
+- **[Correctness]** [FILE:LINE] Description of critical issue
+  **Why:** Explanation of impact — what breaks, who is affected, how likely
+- **[Security]** [FILE:LINE] Description
+  **Why:** ...
+
+### Warning (should fix)
+- **[Performance]** [FILE:LINE] Description
+  **Why:** Explanation of risk — what degrades, under what conditions
+- **[Reliability]** [FILE:LINE] Description
+  **Why:** ...
+
+### Nitpick (consider for next time)
+- **[Design]** [FILE:LINE] Description
+  **Why:** Explanation of improvement — readability, maintainability, conventions
+
+### What Looks Good
+- Brief acknowledgment of well-done aspects (1-3 bullet points max)
+```
+
+**Severity guidelines:**
+- **Critical:** Will cause bugs in production, security vulnerability, data loss, or crash. Must fix.
+- **Warning:** Likely to cause problems at scale, makes future bugs likely, or degrades reliability/performance meaningfully. Should fix.
+- **Nitpick:** Style, conventions, minor improvements. Won't break anything but worth noting.
+
+**Rules:**
+- Maximum 20 items total (prioritize by severity, then by category)
+- Every item must tag its review dimension: `[Correctness]`, `[Security]`, `[Performance]`, `[Reliability]`, `[Design]`, `[Best Practices]`, `[Testing]`
+- Every item must reference a specific file and line
+- Every item must explain **why** it matters — the impact, not just the symptom
+- Include a brief "What Looks Good" section (2-3 items) — acknowledge strong patterns so they're reinforced. This isn't cheerleading — it's calibrating signal.
+- If you genuinely find nothing wrong after all 7 dimensions, say so — but that's rare
+
+### 11. Next Steps
+
+After presenting the review:
+
+If there are **Critical** or **Warning** items:
+> "Review found issues that should be addressed. Fix them with `/sk:debug`, commit with `/sk:smart-commit`, then re-run `/sk:review` to verify."
+
+If there are only **Nitpick** items (no Critical/Warning):
+> "Review complete — no critical issues found, but there are some nitpicks. Would you like to fix them now, or proceed to `/sk:finish-feature`?"
+
+If the user wants to fix nitpicks, loop back to `/sk:debug` + `/sk:smart-commit` → `/sk:review`.
+
+If the review is **completely clean**:
+> "Review complete — no issues found. Run `/sk:finish-feature` to finalize the branch and create a PR."
+
+---
+
+## Model Routing
+
+Read `.shipkit/sk:config.json` from the project root if it exists.
+
+- If `model_overrides["sk:review"]` is set, use that model — it takes precedence.
+- Otherwise use the `profile` field. Default: `balanced`.
+
+| Profile | Model |
+|---------|-------|
+| `full-sail` | opus (inherit) |
+| `quality` | opus (inherit) |
+| `balanced` | sonnet |
+| `budget` | sonnet |
+
+> `opus` = inherit (uses the current session model). When spawning sub-agents via the Agent tool, pass `model: "<resolved-model>"`.

package/skills/sk:review/references/security-checklist.md

@@ -0,0 +1,223 @@
+# Security Checklist (OWASP Top 10 Condensed)
+
+Use this checklist when reviewing code changes. For each category, grep for the listed patterns and inspect matches in the diff.
+
+---
+
+## 1. Injection (SQL, NoSQL, Command, Template)
+
+**Grep patterns:**
+```
+query(           — raw SQL queries
+exec(            — command execution
+eval(            — code evaluation
+system(          — system calls
+subprocess       — Python subprocess
+child_process    — Node.js child process
+${               — template literals in queries
+f"               — Python f-strings in queries
+.format(         — Python format strings in queries
+% (              — Python % formatting in queries
+```
+
+**What to check:**
+- Are user inputs parameterized/escaped before use in queries?
+- Are shell commands built from user input?
+- Is `eval()` or equivalent used with dynamic input?
+
+---
+
+## 2. Broken Authentication
+
+**Grep patterns:**
+```
+password         — hardcoded passwords
+secret           — hardcoded secrets
+token            — token handling
+jwt              — JWT implementation
+session          — session management
+cookie           — cookie settings
+httpOnly         — cookie security flags
+secure:          — secure flag on cookies
+sameSite         — CSRF protection
+bcrypt           — password hashing
+argon2           — password hashing
+md5              — weak hashing (red flag)
+sha1             — weak hashing (red flag)
+```
+
+**What to check:**
+- Are passwords hashed with bcrypt/argon2 (not MD5/SHA1)?
+- Do JWTs have expiration and proper validation?
+- Are session cookies httpOnly, secure, sameSite?
+- Is there rate limiting on auth endpoints?
+
+---
+
+## 3. Sensitive Data Exposure
+
+**Grep patterns:**
+```
+console.log      — logging sensitive data
+print(           — logging sensitive data
+logger.          — logging sensitive data
+.env             — environment file references
+process.env      — environment variable access
+os.environ       — Python environment access
+API_KEY          — API key references
+SECRET           — secret references
+PASSWORD         — password references
+PRIVATE_KEY      — private key references
+credential       — credential references
+```
+
+**What to check:**
+- Are secrets loaded from environment variables (not hardcoded)?
+- Is sensitive data excluded from logs?
+- Are API keys, tokens, passwords in `.gitignore`?
+- Is PII encrypted at rest and in transit?
+
+---
+
+## 4. XML External Entities (XXE)
+
+**Grep patterns:**
+```
+xml.parse        — XML parsing
+DOMParser        — browser XML parsing
+lxml             — Python XML
+etree            — Python XML
+<!ENTITY         — XML entity declarations
+```
+
+**What to check:**
+- Is external entity processing disabled?
+- Are XML parsers configured securely?
+
+---
+
+## 5. Broken Access Control
+
+**Grep patterns:**
+```
+isAdmin          — admin checks
+role             — role-based access
+permission       — permission checks
+authorize        — authorization logic
+@auth            — auth decorators
+middleware       — middleware (auth)
+req.user         — user from request
+currentUser      — current user reference
+req.params.id    — user-controlled IDs (IDOR risk)
+```
+
+**What to check:**
+- Does every endpoint check authorization (not just authentication)?
+- Are object IDs validated against the current user (prevent IDOR)?
+- Is there server-side access control (not just UI hiding)?
+- Are admin routes protected?
+
+---
+
+## 6. Security Misconfiguration
+
+**Grep patterns:**
+```
+CORS             — CORS configuration
+Access-Control   — CORS headers
+origin: '*'      — permissive CORS (red flag)
+debug            — debug mode
+DEBUG = True     — Python debug mode
+NODE_ENV         — environment setting
+helmet           — security headers (Node.js)
+X-Frame-Options  — clickjacking protection
+Content-Security — CSP headers
+```
+
+**What to check:**
+- Is CORS configured to specific origins (not `*`)?
+- Is debug mode off in production?
+- Are security headers set (CSP, X-Frame-Options, HSTS)?
+- Are default credentials changed?
+
+---
+
+## 7. Cross-Site Scripting (XSS)
+
+**Grep patterns:**
+```
+innerHTML        — direct HTML insertion
+dangerouslySetInnerHTML  — React raw HTML
+v-html           — Vue raw HTML
+{!! !!}          — Laravel unescaped output
+| safe            — Django/Jinja safe filter
+document.write   — DOM manipulation
+.html(           — jQuery HTML insertion
+DOMPurify        — sanitization library (good sign)
+sanitize         — sanitization
+escape           — escaping
+```
+
+**What to check:**
+- Is all user-generated content escaped before rendering?
+- Is `dangerouslySetInnerHTML` / `innerHTML` used with sanitized content?
+- Are URL parameters reflected without encoding?
+
+---
+
+## 8. Insecure Deserialization
+
+**Grep patterns:**
+```
+JSON.parse       — JSON deserialization
+pickle           — Python pickle (dangerous)
+yaml.load        — YAML loading (use safe_load)
+unserialize      — PHP deserialization
+Marshal.load     — Ruby deserialization
+deserialize      — generic deserialization
+```
+
+**What to check:**
+- Is `pickle` used with untrusted data? (Critical vulnerability)
+- Is `yaml.load` used instead of `yaml.safe_load`?
+- Is deserialized data validated before use?
+
+---
+
+## 9. Using Components with Known Vulnerabilities
+
+**Check commands:**
+```bash
+npm audit                          # Node.js
+pip-audit                          # Python
+bundle audit                       # Ruby
+composer audit                     # PHP
+govulncheck ./...                  # Go
+cargo audit                        # Rust
+```
+
+**What to check:**
+- Are dependencies up to date?
+- Are there known vulnerabilities in direct dependencies?
+- Is there a lockfile committed?
+
+---
+
+## 10. Insufficient Logging & Monitoring
+
+**Grep patterns:**
+```
+catch            — error handling (are errors logged?)
+except           — Python error handling
+rescue           — Ruby error handling
+console.error    — client-side error logging
+logger.error     — server-side error logging
+winston          — logging library
+pino             — logging library
+```
+
+**What to check:**
+- Are authentication failures logged?
+- Are authorization failures logged?
+- Are errors caught and logged (not swallowed)?
+- Do logs include enough context for debugging without sensitive data?

package/skills/sk:schema-migrate/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: sk:schema-migrate
+description: "/sk:schema-migrate — Multi-ORM Schema Change Analysis"
+---
+
+# /sk:schema-migrate — Multi-ORM Schema Change Analysis
+
+**Invocation:** `/sk:schema-migrate`
+
+Analyzes pending schema changes across **5 ORMs** and provides safe, dialect-specific migration
+guidance. Auto-detects the ORM from project files — no configuration needed.
+
+**Supported:** Drizzle ORM · Prisma · Laravel + Eloquent · SQLAlchemy + Alembic · Rails + ActiveRecord
+
+---
+
+## Overview: 5-Phase Analysis
+
+1. **Detect ORM** — Read project files, identify ORM + dialect, load the correct analysis module
+2. **Classify Changes** — Parse diffs, categorize by risk, detect unsafe patterns
+3. **Present Risk Report** — Formatted report with warnings and dialect-specific notes
+4. **Per-Change Migration Plans** — Concrete safe paths for breaking/risky changes
+5. **Command Recommendations** — ORM-specific workflows and commands
+
+---
+
+## Phase 1: ORM Detection
+
+### Step 1 — Read in Parallel
+
+Read the following files simultaneously (read-only, tolerate missing files):
+
+```
+drizzle.config.ts        prisma/schema.prisma
+drizzle.config.js        composer.json
+alembic.ini              Gemfile
+package.json             supabase/sk:config.toml
+```
+
+### Step 2 — Apply Priority Rules (first match wins)
+
+| Priority | ORM | Definitive Signal | Secondary Check |
+|----------|-----|-------------------|-----------------|
+| 1 | Drizzle | `drizzle.config.ts` or `drizzle.config.js` exists | `package.json` → `drizzle-orm` dep |
+| 2 | Prisma | `prisma/schema.prisma` exists | `package.json` → `@prisma/client` |
+| 3 | Laravel | `composer.json` → `laravel/framework` key | `database/migrations/` exists |
+| 4 | SQLAlchemy | `alembic.ini` exists | `alembic/versions/` exists |
+| 5 | Rails | `Gemfile` → `rails` or `activerecord` gem | `db/migrate/` + `db/schema.rb` |
+
+**Supabase overlay (independent check):** If `supabase/sk:config.toml` exists → set `isSupabase = true`. This adds Supabase CLI commands in Phase 5, alongside standard ORM commands.
+
+**Ambiguity:** If two definitive signals match (e.g., monorepo), ask the user before proceeding:
+> "Found both `drizzle.config.ts` (Drizzle) and `composer.json` (Laravel). Which ORM should I analyze?"
+
+**Unknown:** If no signal matches any ORM, report:
+> "Could not detect ORM. Checked for: drizzle.config.ts, prisma/schema.prisma, composer.json (laravel/framework), alembic.ini, Gemfile (rails/activerecord). Please specify which ORM this project uses."
+
+For more detailed detection heuristics and dialect rules, see `references/detection.md`.
+
+### Step 3 — Report Detection Result
+
+```
+Detected: [ORM] ([dialect]) — loading orms/[orm].md
+```
+
+Examples:
+- `Detected: Drizzle ORM (SQLite) — loading orms/drizzle.md`
+- `Detected: Prisma (PostgreSQL + Supabase) — loading orms/prisma.md`
+- `Detected: Laravel + Eloquent (MySQL) — loading orms/laravel.md`
+- `Detected: SQLAlchemy + Alembic (PostgreSQL) — loading orms/sqlalchemy.md`
+- `Detected: Rails + ActiveRecord (PostgreSQL) — loading orms/rails.md`
+
+### Step 4 — Load and Execute ORM Module
+
+Read the appropriate file from `orms/` and execute **Phases 2 through 5** as defined there:
+
+| ORM | File |
+|-----|------|
+| Drizzle | `orms/drizzle.md` |
+| Prisma | `orms/prisma.md` |
+| Laravel | `orms/laravel.md` |
+| SQLAlchemy | `orms/sqlalchemy.md` |
+| Rails | `orms/rails.md` |
+
+---
+
+## Safety Contract
+
+✅ **Read-only analysis** — this skill never modifies files, schemas, or databases
+
+✅ **No auto-execution** — never runs `db:push`, `db:generate`, `db:migrate`, `prisma migrate`, `php artisan migrate`, `alembic upgrade`, `rails db:migrate`, or `supabase push` automatically
+
+✅ **User confirms** — user must read and understand the risk report before proceeding
+
+✅ **ORM + dialect-specific guidance** — recommendations are tailored to the detected stack
+
+✅ **Data safety first** — flags orphan rows, duplicates, NULL violations, and breaking changes before they cause data loss
+
+---
+
+## Known Limitations
+
+1. **MongoDB (Prisma):** Prisma + MongoDB does not use migration files — schema-migrate reports this and stops analysis
+2. **Autogenerate blindspots (SQLAlchemy):** Alembic cannot detect column renames, check constraints, or server defaults from model files alone
+3. **Remote schema sync:** Supabase remote schema comparison requires a valid `SUPABASE_ACCESS_TOKEN` — falls back to local-only analysis if unavailable
+4. **Custom SQL migrations:** Manually written SQL migration files (outside ORM conventions) cannot be fully parsed — user must verify independently
+5. **Type cast validation:** Cannot predict if a type cast will succeed at runtime — always recommend staging test first
+
+---
+
+## Model Routing
+
+Read `.shipkit/sk:config.json` from the project root if it exists.
+
+- If `model_overrides["sk:schema-migrate"]` is set, use that model — it takes precedence.
+- Otherwise use the `profile` field. Default: `balanced`.
+
+| Profile | Model |
+|---------|-------|
+| `full-sail` | opus (inherit) |
+| `quality` | sonnet |
+| `balanced` | sonnet |
+| `budget` | haiku |
+
+> `opus` = inherit (uses the current session model). When spawning sub-agents via the Agent tool, pass `model: "<resolved-model>"`.