build-system-decodelisted

# Build System Decode ## Purpose A repeatable way to understand and drive an unfamiliar build, so you can answer "what can I run, what does it do, and how do I build/test just my package?" without holding the whole dependency graph in your head. Detect the tool from its manifest, use the tool's own introspection instead of hand-parsing config, and always find the narrowest command that gets your package green. ## Detection: manifest → build system | Manifest file(s) | Build system | Introspection command | |------------------|--------------|-----------------------| | `Makefile` | Make | `make help`, `make -qp`, grep `.PHONY` | | `BUILD(.bazel)`, `WORKSPACE`, `MODULE.bazel` | Bazel | `bazel query //...` | | `build.gradle(.kts)`, `settings.gradle` | Gradle | `./gradlew tasks --all` | | `pom.xml` | Maven | `mvn help:describe`, `<modules>` | | `package.json` `scripts` + lockfile | npm/pnpm/yarn | read `scripts`, `<pm> run` | | `nx.json`, `project.json` | Nx | `nx graph`, `nx show projects` | | `turbo.json` | Turborepo | `turbo run build --dry` | | `CMakeLists.txt` | CMake | `cmake --build . --target help` | | `Cargo.toml` (`[workspace]`) | cargo | `cargo metadata`, `--workspace` | | `go.mod`, `go.work` | go build | `go list ./...` | A repo often has **two layers**: a top-level orchestrator (Make, Nx, Turbo, Bazel) driving per-language builds underneath. Identify both. ## The three questions to answer 1. **What targets exist?** Use the tool's list/query command, never invent a