database-design-quality-review

Database Design Quality Review

Review ERD, DDL, ORM schema, data ownership, lifecycle, query constraints, transaction concurrency, migration compatibility, and recovery design before implementation or migration. Output DB-## findings and verification preparation, without connecting to a real database, running queries, or approving go-live on behalf of the Human.

When to Use

• Need to check model integrity, constraints, indexes, lifecycle/privacy, and data ownership.
• Need to identify transaction isolation, concurrency, migration rollback, backup and recovery, and performance risks.
• Need to deliver a limited design review when DDL or migration materials are incomplete.

Not applicable to executing migrations, connecting to production databases, stress-testing queries, or fabricating business rules from table names.

Output Format Options

• Default output is Markdown; when the user requests tables, CSV, or JSON, retain the same evidence, status, impact, responsible role, and verification fields.
• Do not write structured formats or static checklists as execution, pass, approval, or release evidence.

How to Use

1. First read this Skill's main Prompt and provide the goal, scope, materials, environment, and existing evidence.
2. Execute according to the Prompt's input audit and output contract; when information is missing, deliver a bounded initial version.
3. For each finding, retain the source, evidence status, impact, responsible role, closure conditions, and verification method.

Working Approach

1. Read prompts/database-design-quality-review.md, audit the goal, version, database boundaries, and evidence.
2. Classify the input as known、missing、conflicting、stale、out_of_scope、assumptions。
3. Build a coverage matrix by object, constraint, index, transaction/concurrency, lifecycle, migration, and recovery, using DB-## to bind sources and minimum evidence.
4. Output facts, evidence-based inferences, recommendations, and Human decisions, giving impact, responsible role, closure conditions, and verification method.
5. When there is no execution identity, time, environment, and raw results, do not write that a database operation succeeded.

Core Constraints

• Do not connect to, write to, migrate, or query a real database; do not run benchmarks or recovery drills.
• Do not invent business rules, thresholds, retention periods, or privacy classifications from table names, field names, or common patterns.
• Each DB-## contains at least the object, source/evidence, constraint/index, transaction/concurrency, migration rollback, impact, responsible role, and verification method.
• Examples must be desensitized; when evidence is missing, mark missing、unverified、unexecuted or unassessed。

Reference Files

• Before each output, you must read prompts/database-design-quality-review.md。
• For regression, read evals/eval.yaml and test cases; static design checks do not prove database behavior.
• Trigger checks use evals/trigger-prompts.csv and evals/local-rules.json; when the selection trace is missing, report BLOCKED。

Best Practices

• Prioritize high-impact and verifiable gaps, and use minimal experiments or supplementary evidence actions to reduce uncertainty.
• Separate facts, evidence-supported inferences, recommendations, and Human decisions, avoiding escalating assumptions into conclusions.

Pre-Delivery Self-Check

• Audited the object, version, ownership, scope, and evidence
• Covered the model, constraints, indexes, lifecycle/privacy, transaction concurrency, migration, performance, backup and recovery, and test readiness
• Each DB-## has minimum evidence, impact, responsible role, actions, and verification
• All examples use desensitized data and are not connected to a real database
• Did not present DDL existence or static checks as a successful migration or production approval

Common Misconceptions

• Only checking tables and fields, not constraints, lifecycle, rollback, and recovery.
• Treating the existence of an index as proof that query performance has been verified.
• Treating the ability to parse a migration script as backward compatibility and rollback capability.