Dev Environment Manager
What It Does
Manages reproducible development environments as code. Creates and maintains devcontainer configurations, dotfiles, tool version management, and environment provisioning scripts. Ensures every developer on a team has an identical, working environment — eliminating "works on my machine" and reducing setup time from hours to minutes.
Iron Laws (NEVER violate)
- Environment as code — Dev environment configuration lives in version control alongside application code. No manual setup steps.
- Deterministic builds — Same configuration always produces the same environment. Pinned versions, locked dependencies, checksum verification.
- Isolation by default — Every project gets its own isolated environment. No global dependency conflicts.
- Fast start — New team member must go from zero to running tests in under 15 minutes. Longer = broken onboarding.
Red Flags (STOP immediately)
- Drifting environments — Two developers on same project have different tool versions → environment config not enforced
- "Works on my machine" — Bug that reproduces on one machine but not another → environment inconsistency
- Secret in config — API keys, tokens, or credentials in devcontainer or dotfiles config → security breach
- Platform lock-in — Environment only works on macOS → exclude Linux/Windows developers
Common Rationalizations (self-deception)
- "Everyone installs tools differently, it's fine" → Tool version differences are a leading cause of "mystery bugs."
- "Devcontainers add overhead" → The overhead of debugging environment issues is 10x the overhead of containers.
- "We'll standardize environments later" → Environment drift compounds. The longer you wait, the harder the fix.
When To Use
- Setting up a new project with multiple developers
- Standardizing tool versions across a team (Node, Python, Go, Rust, etc.)
- Migrating from manual setup to devcontainers
- Creating dotfiles management for personal development setup
- Troubleshooting "works on my machine" issues
Human Partner Signals (escalate to human)
- Hardware constraints — Environment requires resources (RAM, disk) some developers don't have → lightweight alternative needed
- License restriction — Required tool requires paid license → procurement decision
- Security policy conflict — Devcontainer configuration conflicts with corporate security policy → negotiation needed
- Legacy system — Project can't be containerized due to legacy dependencies → alternative approach needed
Pipeline
- Audit: inventory current tools, versions, and manual setup steps across the team
- Design: choose environment strategy — devcontainers, nix, docker-compose, or hybrid
- Implement: create devcontainer.json / Dockerfile / nix flake with pinned versions
- Configure: set up dotfiles — shell config, editor settings, git aliases, linting/formatting
- Automate: create bootstrap script — one command to install, configure, and verify
- Test: verify environment works on all supported platforms (macOS, Linux, Windows/WSL)
- Document: add setup instructions (one-liner), troubleshooting guide, and update process
Verification Checklist
Related Skills
onboarding-automator — Dev environment is the first step of onboardingdocker-k8s-pro — Container expertise for devcontainer designdocumentation-generator — Environment setup docs generated and kept currentsupply-chain-verifier — Verify tool and dependency provenance