<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

database-modeling

This skill is part of Misbah Khursheed's Build Like This workflow. Thinking, evidence, and explicit trade-offs come before generated output.

Project identity and sources of truth

The repository where this skill is installed is the host project being built. Build Like This is the method used to build it; mstack only installs and reconciles method resources. Do not assume mstack or Build Like This is the product unless project-owned sources explicitly identify this repository as mstack itself.

Use project-owned docs/, decisions, executable code, and tests as sources of truth. .mstack/templates/ are reference scaffolds to copy and adapt into project-owned documents, not product requirements and not a replacement for docs/.

Purpose

Turn domain rules and access patterns into a persistence design that remains correct under concurrency, growth, and deployment change.

Required inputs

• Entities, ownership, lifecycle/state transitions, cardinality, and invariants.
• Tenant and sensitive-data boundaries, retention/deletion rules, and recovery expectations.
• Read/write patterns, expected scale, consistency needs, and current schema constraints.

If a missing input would materially change the result, state the gap and obtain or discover it before proceeding. Otherwise label the assumption and continue.

Process

1. Identify aggregate ownership and distinguish durable facts from derived or cached values.
2. Define tables/collections, keys, relationships, nullability, uniqueness, checks, and deletion behavior.
3. Map transaction and concurrency boundaries, including race conditions and idempotent writes.
4. Derive minimal indexes from concrete access patterns and validate critical queries against representative data.
5. Classify sensitive fields and define tenant isolation, retention, audit, backup, and restore behavior.
6. Design expand-migrate-contract rollout with restartable backfill, compatibility window, monitoring, and recovery.

Output contract

• Entity/relationship and ownership model with explicit invariants and constraints.
• Access-pattern/index table and transaction/concurrency behavior.
• Migration/backfill/rollback-or-forward plan plus integrity, isolation, and query tests.

Guardrails

• Do not add an index without naming the query it serves and its write/storage cost.
• Do not use application validation as the only protection for durable invariants.
• Do not propose destructive migration steps without backup, compatibility, and recovery evidence.

Delegation and parallel safety

• Material lifecycle work must delegate at least one bounded specialist lane when subagents are available. Prefer two or more concurrent lanes only for independent evidence gathering, analysis, or non-overlapping file ownership.
• The active lead owns integration and acceptance. Supporting agents do not recursively delegate unless explicitly promoted to lead a named lane.
• Assign distinct outputs and ownership. Serialize shared docs, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• When subagents are unavailable, perform the same named specialist passes sequentially and state that constraint instead of implying parallel verification.
• Delegation never grants permission for outreach, consequential external actions, destructive changes, paid resources, or production operations.

End with the evidence gathered, verification performed, and any residual risk or unresolved decision.