37signals-migration

Generate reversible UUID-based migrations for multi-tenant Rails tables without foreign keys.

1|Updated Feb 3, 2026
One-click install
npx skills add https://github.com/joshyorko/agent-skills --skill 37signals-migration
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: 37signals-migration
Source: https://github.com/joshyorko/agent-skills/tree/main/plugins/rails-37signals-patterns/skills/37signals-migration
Command: npx skills add https://github.com/joshyorko/agent-skills --skill 37signals-migration

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Creates database migrations that use UUIDs as primary keys, add account_id for multi-tenancy, and intentionally avoid foreign key constraints to align with 37signals-style patterns.

Core Features & Use Cases

  • UUID-based primary keys for all tables to improve security and data portability.
  • Automatic multi-tenant scaffolding with account_id and composite/index patterns for common queries.
  • Reversible migrations with simple, explicit schemas for resources like cards, closures, assignments, and comments.

Quick Start

Generate a UUID-based migration for your multi-tenant tables and apply it with bin/rails db:migrate.

Frequently Asked Questions about 37signals-migration

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

FAQPage Schema
How do I create UUID-based migrations for a multi-tenant Rails app?

UUID migrations replace integer primary keys with UUIDs and add an account_id column for multi-tenancy. They intentionally avoid foreign key constraints to align with 37signals-style database design patterns.

Why should I avoid foreign key constraints in Rails multi-tenant database design?

Avoiding foreign key constraints in multi-tenant Rails database design allows greater data portability and aligns with 37signals-style patterns. Instead of constraints, these migrations enforce data integrity through appropriate composite indexes and simple, auditable schemas.

What is the best way to structure multi-tenant migrations for core resources like cards and boards?

The best way to structure multi-tenant migrations for resources like cards and boards is to apply UUID primary keys and account_id columns across all tables. Include timestamps and appropriate indexes while ensuring the migrations remain simple and reversible.

Can I use reversible migrations when adding UUID primary keys and account_id columns?

Yes, reversible migrations are explicitly supported when adding UUID primary keys and account_id columns. The generated schemas are simple and explicit, ensuring that bin/rails db:rollback can cleanly undo the multi-tenant scaffolding without leaving orphaned indexes.

Does this multi-tenant migration approach include database indexes for common queries?

Yes, the multi-tenant migration approach includes appropriate indexes and composite patterns tailored for common queries. It automatically scaffolds these indexes alongside the account_id and UUID primary keys to optimize query performance.