DevOps

Environment Replicator

Analyzes your application and generates docker-compose.yml, seed scripts, and .env.example for a complete reproducible local dev environment.

SKILL.md

SKILL.md
---
description: Generate docker-compose.yml, seed scripts, and .env.example for local dev
allowed-tools: Bash, Read, Write, Glob, Grep
context:
  - type: command
    command: "cat package.json 2>/dev/null"
  - type: command
    command: "cat docker-compose.yml 2>/dev/null"
---

# Environment Replicator

Analyze the application's code, configuration, and dependencies to generate a complete local development environment setup: `docker-compose.yml` with all required services, `.env.example` with documented variables, seed/migration scripts, and setup instructions.

## Steps

1. **Identify required services.** Scan the codebase for:
   - **Database**: look for connection strings, ORM config (`prisma/schema.prisma`, `drizzle.config.*`, `knexfile.*`, `ormconfig.*`), or driver imports (`pg`, `mysql2`, `mongodb`, `redis`)
   - **Cache**: look for Redis/Memcached client usage (`ioredis`, `redis`, `memcached`)
   - **Message queue**: look for RabbitMQ, Kafka, SQS, or BullMQ imports
   - **Search**: look for Elasticsearch, Meilisearch, or Typesense clients
   - **Object storage**: look for S3/MinIO client usage
   - **Email**: look for SMTP configuration or email service imports (Nodemailer, SendGrid, etc.)
   - **Auth services**: look for OAuth providers, LDAP config, or auth service URLs

2. **Collect all environment variables.** Grep the codebase for:
   - `process.env.*` and `import.meta.env.*` patterns
   - `.env`, `.env.local`, `.env.example` files
   - Config files that reference env vars
   For each variable, determine:
   - Purpose (from context or naming convention)
   - Whether it is a secret (passwords, API keys, tokens)
   - Whether it has a sensible default for local development
   - Which service it connects to

3. **Check for existing Docker setup.** If `docker-compose.yml` already exists:
   - Read it and identify what is already defined
   - Note what is missing based on step 1
   - Generate an enhanced version rather than starting from scratch

4. **Generate docker-compose.yml.** Create a compose file with:
   - **Service for each dependency** identified in step 1
   - Use official images with pinned major versions (e.g., `postgres:16`, `redis:7`)
   - Configure health checks for each service
   - Set up named volumes for data persistence
   - Map ports to conventional local ports
   - Add a depends_on chain reflecting startup order
   - Include the application itself as a service (with `build: .` or `command: npm run dev`) if appropriate
   - Add labels for documentation

5. **Generate .env.example.** Create a documented env file:
   ```
   # =====================
   # Database Configuration
   # =====================
   DATABASE_URL=postgresql://postgres:postgres@localhost:5432/myapp_dev
   # DATABASE_URL=mysql://root:root@localhost:3306/myapp_dev  # Uncomment for MySQL

   # =====================
   # Redis Configuration
   # =====================
   REDIS_URL=redis://localhost:6379

   # =====================
   # Authentication
   # =====================
   # Generate with: openssl rand -base64 32
   JWT_SECRET=change-me-in-production

   # =====================
   # External Services (optional for local dev)
   # =====================
   # SENDGRID_API_KEY=
   # STRIPE_SECRET_KEY=
   ```
   Group variables by service, add comments explaining each, provide working defaults for local dev, and clearly mark secrets.

6. **Generate seed scripts.** Based on the database schema:
   - Read migration files or schema definitions
   - Generate a seed script that populates the database with realistic sample data
   - Include admin/test user accounts with documented credentials
   - Add enough data to exercise pagination, search, and filtering features
   - Write the script in the project's language/framework (Prisma seed, SQL file, etc.)

7. **Generate a setup script.** Create a `scripts/setup-dev.sh` that:
   ```bash
   #!/bin/bash
   set -e

   echo "Copying environment template..."
   cp -n .env.example .env

   echo "Starting services..."
   docker compose up -d

   echo "Waiting for database..."
   # Health check loop

   echo "Running migrations..."
   # Project-specific migration command

   echo "Seeding database..."
   # Project-specific seed command

   echo "Development environment ready!"
   ```

8. **Write all files** and provide a summary of what was generated and how to use it.

## Rules

- Never include real secrets, API keys, or production credentials in any generated file.
- Use `localhost` URLs in `.env.example` that match the docker-compose port mappings.
- Pin Docker image versions to major (not `latest`) for reproducibility.
- If a service is optional for development (e.g., email), include it commented out in docker-compose.
- Add a `.dockerignore` file if one does not already exist.
- The setup script must be idempotent — safe to run multiple times.

How It Works

The "works on my machine" problem persists because setting up a development environment involves undocumented tribal knowledge: which services to install, what env vars to set, how to seed the database. This skill reverse-engineers that knowledge from the codebase itself, producing a reproducible setup that any developer can run with a single command.

The environment variable analysis is particularly thorough. By grepping the entire codebase for `process.env` usage, it discovers variables that may not be in any existing `.env.example` — the ones that were added in a PR six months ago and never documented. Grouping them by service and adding explanatory comments transforms a cryptic list of variable names into a self-documenting configuration file.

The idempotent setup script is the glue that makes everything work together. Rather than a README with six separate commands that must be run in order, the script handles the entire sequence: copy env template, start containers, wait for health checks, run migrations, seed data. The `-n` flag on `cp` prevents overwriting an existing `.env` file, making the script safe to rerun after pulling new changes that add services.