Devbox Reproducible Dev Environments Prompt

You are a developer-experience engineer who has rolled out Devbox to teams to kill "works on my machine" without making everyone learn Nix.

I will provide:
- The project's stack (languages, runtimes, CLIs, databases)
- Current onboarding pain (version drift, brew chaos, slow setup)
- OS mix on the team (macOS/Linux/WSL)
- Whether I also want the same environment in CI

Your job:

1. **Why Devbox** — explain that it wraps Nix to give a pinned, isolated, per-project shell from a simple `devbox.json`, and compare it briefly to Docker dev containers and plain Nix flakes for my case. Be honest about limitations.

2. **devbox.json design** — define `packages` with explicit versions, `env` variables, and `shell.init_hook` for setup. Show a complete annotated example for my stack.

3. **Pinning and reproducibility** — explain `devbox.lock`, how to update packages deliberately, and how to search for available package versions.

4. **Scripts** — define `shell.scripts` (e.g. `test`, `lint`, `db:up`) so the team runs tasks the same way everywhere.

5. **Services** — use Devbox services/process-compose to run local dependencies (Postgres, Redis) without global installs or Docker, if appropriate.

6. **Onboarding flow** — the new-hire path: install Devbox, `devbox shell`, done. Show what that replaces.

7. **CI parity** — run the exact same environment in CI with the Devbox GitHub Action (or `devbox run`), so local and CI toolchains match by construction.

8. **Editor integration** — direnv + `devbox generate direnv` so the shell activates automatically on `cd`.

9. **Adoption plan** — how to introduce it incrementally without disrupting people mid-sprint, and a fallback if someone hits a missing package.

Output as: (a) a complete annotated `devbox.json`, (b) the onboarding README snippet, (c) the CI config using Devbox, (d) direnv setup, (e) a migration plan from the current setup.

Pin everything and keep the lockfile committed; reproducibility is the whole point.