seed

Seed -- Database Seeding & Test Data

Activate When

• /godmode:seed, "seed the database", "generate test data"
• "create fixtures", factory patterns (FactoryBot, fishery)
• Fake data generation (Faker.js, Faker Python)
• Data anonymization for production snapshots

Workflow

Step 1: Detect Environment

# Detect ORM and factory libraries
grep -r "prisma\|typeorm\|sequelize\|django\|sqlalchemy" \
  package.json pyproject.toml Gemfile 2>/dev/null
ls prisma/seed.ts db/seeds.rb scripts/seed* 2>/dev/null
grep -r "@faker-js\|faker\|factory_bot\|Bogus" \
  package.json pyproject.toml 2>/dev/null

SEEDING ENVIRONMENT:
Language: <TS | Python | Go | Ruby | Java>
ORM: <Prisma | Drizzle | SQLAlchemy | ActiveRecord>
Database: <PostgreSQL | MySQL | SQLite | MongoDB>
Existing seeds: <path or "none detected">
Factory lib: <fishery | factory_boy | none>
Faker lib: <@faker-js/faker | Faker Python | none>

Step 2: Factory Pattern

Library selection:
  TypeScript: fishery
  Python: factory_boy
  Ruby: FactoryBot
  Go: table-driven builders + gofakeit
  C#: Bogus
  Java: Instancio

Key patterns:
  Base factory with faker defaults + sequence IDs
  Traits for variants (admin, inactive, published)
  build() for in-memory, create() for persisted
  buildList(N) for batches
  Override any field at call site

Step 3: Seed Script Architecture

IDEMPOTENT SEED RULES:
1. ALWAYS upsert (insert or update), never plain insert
2. Stable identifiers (slug, email) not auto-increment
3. Dependency order (users before posts)
4. Wrap each group in transaction
5. Log: created vs skipped vs updated
6. Re-runnable: running twice = same result

SEED STRUCTURE:
  faker.seed(42) for determinism
  Phase 1: reference data (roles, categories via upsert)
  Phase 2: core entities (fixed + random users)
  Phase 3: dependent entities (posts, comments)
  Check count vs target, only create delta

Step 4: Relationship Handling

Seed in topological order: reference -> independent -> first-level deps -> second-level deps -> M:N joins -> derived data.