setup-diagnosislisted

# Setup Diagnosis ## Purpose The biggest day-one sink is getting a green build: missing dependencies, the wrong runtime version, OS-specific breakage, missing env vars, and silently outdated README steps. This skill provides two things, a **map of where a repo declares what it needs** (so you stop guessing) and a **catalog of the common failure modes and their fixes**: so bootstrapping becomes detect → run → diagnose → verify, not trial and error. ## Principle: read the declared requirements, don't guess A repo almost always tells you what it needs, in machine-readable files. Trust those over prose READMEs, which drift. Reconcile pins across files before running anything. ## Where requirements live (quick map) | Need | Look in | |------|---------| | Runtime version | `.nvmrc`, `.tool-versions`, `mise.toml`, `.python-version`, `.ruby-version`, `engines`, `go.mod`, `<java.version>` | | Package manager | `packageManager` field, lockfile kind, `Gemfile`/`poetry.lock`/`Pipfile.lock` | | Dependencies | `package.json`, `pyproject.toml`/`requirements*.txt`, `Gemfile`, `go.mod`, `pom.xml`/`build.gradle`, `Cargo.toml` | | Backing services | `docker-compose.yml`, `.devcontainer/`, infra manifests | | Env vars / config | `.env.example`, `.env.sample`, `config/*.example`, the code that reads config | | The blessed path | `Makefile`/`justfile`/`Taskfile.yml` setup targets, `scripts/setup`, `CONTRIBUTING` | See `setup-signals.md` for the full precedence and reconciliation rules. ## The