Database Workflow Bundle workflow skill. Use this skill when the user needs database development and operations workflow covering SQL, NoSQL, database design, migrations, optimization, and data engineering, while preserving upstream workflow context, copied support files, and provenance before merge or handoff.
Database Workflow Bundle workflow skill. Use this skill when the user needs database development and operations workflow covering SQL, NoSQL, database design, migrations, optimization, and data engineering, while preserving upstream workflow context, copied support files, and provenance before merge or handoff.
Use this skill to review, plan, or guide database work that may affect:
data correctness
schema compatibility
migration safety
query performance
operational reliability
backup and restore readiness
stateful runtime behavior in containers or Kubernetes
This skill is for database change analysis and operational review, not for blind execution. Use it when the task requires judgment across application code, schema or model changes, migration order, runtime behavior, and rollback risk.
If this copy came from an imported upstream workflow, preserve provenance markers, copied support files, and origin notes unless the user explicitly asks for cleanup.
When to Use
Activate this skill when the request includes one or more of the following:
SQL schema changes, indexes, constraints, views, or query rewrites
NoSQL collection or document model changes
migration creation, ordering, rollback, or drift review
slow query investigation or execution-plan review
backup, restore, retention, or recovery-readiness checks
database deployment in Docker, Kubernetes, or other stateful runtimes
data pipeline or batch-load changes that can affect integrity or performance
Do not use this skill as the primary workflow when the task is only:
basic CRUD application coding with no schema or runtime impact
generic infrastructure work unrelated to persistence
pure analytics or BI interpretation with no database design or operations decision
Activation Boundary
Before doing deep review, confirm these inputs:
Engine and version: PostgreSQL, MySQL-compatible, MongoDB, or another named engine.
verify whether an index supports both the filter and sort pattern
avoid approving a rewrite based only on intuition or row-count guesses
Example 3: Document-model change review
{"change":"Make profile.phone required for all user documents","current_state":"Field is missing in legacy documents","deployment":"Validation rule enabled immediately"}
Expected review outcome:
Status: unsafe as proposed
Why: legacy documents and partial-write paths may fail immediately
Safer direction: audit missing-field population, backfill, update writers and readers, then tighten validation
Why:emptyDir is ephemeral and does not provide durable database storage
Safer direction: require persistent storage and stateful deployment review before approval
For worked review samples, open:
examples/review-example.md
examples/troubleshooting-examples.md
Best Practices
Do:
require engine-specific evidence before approving performance claims
separate logical correctness from deployment safety
ask how existing data will satisfy new constraints or validation rules
review rollback feasibility, not just forward migration syntax
confirm persistence, backup, and restore expectations for operational changes
preserve provenance if this skill was imported from an upstream workflow
Do not:
approve destructive DDL without data-shape and rollback analysis
assume a new index is free; check write cost and storage impact
treat document databases as schema-free in production review
accept ephemeral storage for persistent database workloads
recommend credential embedding, unsafe dynamic SQL, or unbounded bulk updates without safeguards
claim a restore strategy exists unless restore steps and dependencies are testable
Troubleshooting
Symptoms: migration fails after adding a NOT NULL column or stricter constraint.
Solution: inspect existing rows first. Recommend a staged migration: add nullable structure, backfill safely, validate results, then enforce the constraint.
Symptoms: query is still slow after adding an index.
Solution: review the actual query plan. Check predicate order, sort requirements, row estimates, stale statistics, and whether the query shape matches the index.
Symptoms: deadlocks or blocked writes appear during deployment.
Solution: inspect migration ordering, lock scope, transaction size, and concurrent write paths. Split high-impact operations and avoid large blocking changes during peak load.
Symptoms: restore procedure completes, but the application still fails or data is incomplete.
Solution: verify dependent objects, credentials, extensions, point-in-time expectations, post-restore validation, and application version compatibility. A technically successful restore is not the same as a usable recovery.
Symptoms: database pod restarts and data disappears.
Solution: verify whether storage is ephemeral, whether the workload should be a StatefulSet, and whether persistent volume claims and storage classes are configured for durable state.
For condensed triage paths, open references/troubleshooting-matrix.md.
Additional Resources
references/review-criteria.md — open when you need a compact engine-aware checklist for schema, migration, performance, backup/restore, and Kubernetes storage review.
references/troubleshooting-matrix.md — open when the task starts from symptoms such as slow queries, deadlocks, failed restores, migration drift, or storage misconfiguration.
examples/review-example.md — open for a worked example of reviewing SQL, document-model, and storage-related changes.
examples/troubleshooting-examples.md — open for symptom-to-decision examples that show what a strong operator response looks like.
Output Template
Use this structure when reporting conclusions:
Decision: approve | approve with conditions | needs evidence | unsafe as proposed
Engine/runtime: <name and version if known>
Change type: <schema | migration | query | operational | restore | pipeline>
Primary risks:
- ...
Evidence reviewed:
- ...
Required follow-ups:
- ...
Reasoning:
- ...
Provenance Notes
If the skill was imported from an upstream repository:
preserve origin markers and copied support files unless the user requests cleanup
avoid rewriting provenance history during technical edits
keep the review focused on the database workflow itself, not on hiding the import path
