database-architect

Design relational database schemas with Expand & Contract migration plans.

Updated Nov 26, 2025
One-click install
npx skills add https://github.com/guiledo/dotfiles --skill database-architect-guiledo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: database-architect
Source: https://github.com/guiledo/dotfiles/tree/main/opencode/.config/opencode/skills/database-architect
Command: npx skills add https://github.com/guiledo/dotfiles --skill database-architect-guiledo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill enforces production-ready database design and safe migration practices to protect data integrity and enable scalable architectures.

Core Features & Use Cases

  • No Data Loss: Use Expand & Contract to add new structures before removing old ones, with phased migrations.
  • Integrity & Performance: Enforce primary/foreign keys, automatic indexing on FKs, and audit fields.
  • Use Case: When evolving a customers table, it guides safe schema changes with backward-compatible migrations.

Quick Start

Draft a normalized schema for a new orders table and propose a safe, multi-phase migration plan using Expand & Contract.

Frequently Asked Questions about database-architect

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I ensure zero-downtime during relational database schema migration?

Zero-downtime database schema migration is achieved through the Expand & Contract workflow, which adds new structures before removing old ones using phased migrations to maintain backward compatibility.

What is the Expand & Contract pattern for evolving database tables?

The Expand & Contract pattern is a database migration technique that adds new schema structures first, migrates data, and then removes old columns to ensure safe, backward-compatible evolution.

How do I design a normalized database schema with automatic indexing?

Designing a normalized database schema with automatic indexing requires enforcing primary and foreign keys, strictly indexing FK constraints, and adding created_at/updated_at audit fields.

Can I use this database design approach for safe migration planning across relational databases?

Yes, this approach applies to schema creation, evolution, and migration planning across relational databases to ensure robust auditing and data integrity.

Why do I need audit fields like created_at and updated_at on new database tables?

Audit fields like created_at and updated_at are needed on new database tables to enforce robust auditing and track record lifecycle changes for production-ready data integrity.

What is the best way to plan a multi-phase migration for an evolving customers table?

The best way to plan a multi-phase migration for an evolving customers table is to use the Expand & Contract workflow, ensuring new structures are added before old ones are removed.