Analyze database design, queries, schema changes, and data access risks for an application. Use this skill when work involves schema design, query review, migrations, or database performance concerns.
Produce a structured, evidence-based database analysis that evaluates schema design, query behavior, migration safety, data repair plans, and performance risks, then turns the result into concrete findings, recommendations, and validation steps.
Use this skill when:
| name | description | default | required | source | example |
|---|---|---|---|---|---|
| requirements | The user's database-related task, concern, or change request. | none | Yes | user or upstream | Review this migration for safety. |
| artifacts | The concrete database artifacts to inspect, such as DDL, SQL, migrations, ORM code, execution plans, metrics, or backfill scripts. |
| discovered from context |
| No |
| user or derived |
| migrations/20260411_add_order_status.sql |
| db_context | Database engine, version, scale, workload shape, data sensitivity, rollout constraints, or other environmental details that materially affect the analysis. | database-agnostic assumptions | No | user or derived | PostgreSQL 16, 50M rows, zero-downtime rollout |
| review_scope | The requested focus, such as design correctness, migration safety, query performance, consistency, or data repair risk. | correctness, safety, and validation | No | user or derived | Focus on performance and rollback safety. |
{db_context} or the artifacts clearly indicate a specific engine.references/dba-checklist.md when the task needs a deeper checklist, a stable report structure, or a reusable migration and performance review rubric.references/migration-safety.md when the task centers on rollout sequencing, locking risk, backfills, repairs, or rollback planning.references/query-performance.md when the task centers on slow queries, missing plans, index fit, fan-out access patterns, or query-shape regressions.{artifacts}, related code, tests, commands, or metrics.{requirements} and {review_scope} before expanding the analysis.{requirements}.{artifacts} and nearby code.{review_scope} when the request is broad.{db_context}: engine, version, scale, traffic pattern, rollout limits, and data sensitivity.references/query-performance.md when query shape, indexing, or hot-path behavior carries most of the risk.references/migration-safety.md when the migration path, repair plan, or compatibility window carries most of the risk.references/dba-checklist.md for deeper coverage when needed.Critical: data loss, corruption, integrity break, uncontrolled downtime, or missing rollback path for a risky changeMajor: significant migration risk, performance regression risk, missing enforcement, unsafe backfill, or important observability gapMinor: lower-impact maintainability, naming, consistency, or optimization issue[confirmed] or [inferred] when that distinction matters.Produce a concise database analysis with this structure:
Summary: what was analyzed and the overall risk shape.Scope and Context: relevant artifacts, boundaries, database context, and assumptions.Findings: ordered by severity with impact, evidence, and [confirmed] or [inferred] markers where needed.Recommendations: concrete schema, query, migration, indexing, batching, or rollback actions.Validation: focused checks to confirm safety, such as tests, explain-plan review, staged migration rehearsal, row-count validation, or rollback rehearsal.Open Questions / Assumptions: only the unresolved points that affect confidence.If no findings are discovered, say so explicitly and still report any residual validation gaps.
User: Review this migration that adds a non-null status column to orders and backfills old rows.
You:
Summary:
- Reviewed the new `orders.status` column, its backfill plan, and the calling write paths. Overall risk is moderate because the column is added safely, but the backfill and constraint tightening sequence is incomplete.
Findings:
Major:
- The migration adds `status` as `NOT NULL` before the backfill is guaranteed complete, which can fail on existing rows or block writers depending on the engine. Evidence: `migrations/20260411_add_order_status.sql`, `OrderRepository.save()`. [confirmed]
Recommendations:
- Add the column as nullable first, deploy dual-write behavior if needed, backfill in batches, validate completion, then tighten the constraint in a later migration.
Validation:
- Rehearse the migration on production-like row counts.
- Verify no `orders` rows remain null before tightening the constraint.
- Review the query plan for the backfill predicate and the new status lookup path.