Db Design

Deep database design workflow—entities and relationships, keys and constraints, normalization vs denormalization, indexing strategy, integrity, and operation...

Security Scan

The skill is a purely instructional, coherent database-design workflow that asks for no credentials, binaries, or installs and stays within its stated scope.

Purpose & Capability

Name and description match the SKILL.md: a six-stage DB design workflow for OLTP schemas. Nothing requested (no env vars, binaries, or installs) is outside what a design workflow would need.

Instruction Scope

Instructions are guidance-only (requirements gathering, modeling, indexing, migrations planning). They do not instruct reading files, accessing environment variables, contacting external endpoints, or performing actions outside design/review tasks.

Install Mechanism

No install spec and no code files. Because this is instruction-only, nothing is written to disk and there is no installation risk.

Credentials

The skill requests no credentials, config paths, or environment variables — appropriate for a design/review workflow that should not need secrets or system access.

Persistence & Privilege

always is false, no special persistence or cross-skill config modifications are requested. Autonomous invocation is allowed by platform default but does not add extra privileges for this instruction-only skill.

Assessment

This skill is guidance-only and appears internally consistent. Before using it in an agent that can act autonomously, note that the skill does not perform migrations or modify systems itself — if you pair it with a migration tool (the doc even suggests db-migrate), review that tool’s install, permissions, and credential needs separately. Also validate any vendor-specific constraints (Postgres, MySQL, cloud-managed DBs) when applying the generic guidance to production systems.

Good OLTP design balances integrity, write paths, query patterns, and evolution—not “third normal form everywhere.”

When to Offer This Workflow

Trigger conditions:

• Greenfield service schema or major new domain
• Performance or integrity issues from ad-hoc tables
• Multi-tenant isolation questions

Initial offer:

Use six stages: (1) domain & access patterns, (2) entities & relationships, (3) keys & constraints, (4) normalization trade-offs, (5) indexing & performance, (6) operations & evolution). Confirm RDBMS and scale expectations.

---

Stage 1: Domain & Access Patterns

Goal: List critical queries and writes: QPS, joins, filters, hot rows.

Exit condition: Top access paths ranked by business importance.

---

Stage 2: Entities & Relationships

Goal: ER model; cardinality; optional vs required relationships.

Practices

• Clear table names; avoid opaque “data” blobs unless documented

---

Stage 3: Keys & Constraints

Goal: Primary keys (surrogate vs natural); foreign keys with explicit ON DELETE policy; unique constraints for business rules.

Multi-tenant

• tenant_id on rows that need isolation; composite keys or indexes as appropriate

---

Stage 4: Normalization Trade-offs

Goal: Normalize to reduce update anomalies; denormalize read hotspots with documented trade-offs.

---

Stage 5: Indexing & Performance

Goal: Indexes serve real queries; watch write amplification and index bloat.

---

Stage 6: Operations & Evolution

Goal: Migration strategy (expand/contract); backup/restore; PII columns flagged.

---

Final Review Checklist

• Access patterns drive schema
• Keys, FKs, and constraints explicit
• Multi-tenant isolation if applicable
• Normalization decisions justified
• Index plan aligned with queries
• Migration and ops considerations noted

Tips for Effective Guidance

• NULL semantics and defaults matter for bugs and migrations.
• Pair with db-migrate for online schema changes.

Handling Deviations

• Document stores: embed vs reference with consistency story.