Optimize Bazel Builds for Large Monorepos

This skill teaches an agent production patterns for Bazel in large-scale monorepos: the core architecture (target, package, label, rule, aspect), a WORKSPACE.bazel configuration loading external rule sets such as aspect_rules_js and rules_python, and a .bazelrc covering performance flags (--jobs=auto, CPU/RAM resource shares), disk and repository caching, remote caching, remote execution, per-platform build configs, and a CI-specific config group. It also covers writing BUILD.bazel files for TypeScript and Python libraries with tests, a custom Starlark rule implementation for building a Docker image, bazel query patterns for dependency analysis (forward deps, reverse deps, changed-target detection, dependency graphs, tagged targets), remote execution platform and toolchain definitions, and build profiling with --profile, --execution_log_json_file, and --memory_profile.

Use it when setting up Bazel for a monorepo, configuring remote caching or remote execution, optimizing build times, writing custom Bazel rules, debugging build issues, or migrating a project to Bazel. It does not apply outside Bazel build optimization - a different tool or domain is out of scope. Its stated best practices: use fine-grained targets for better caching, pin dependencies for reproducible builds, enable remote caching to share build artifacts, use visibility deliberately to enforce architecture boundaries, and write one BUILD file per directory. Its stated anti-patterns: don't use glob for dependencies since explicit deps are clearer, don't commit bazel-* output directories, don't skip WORKSPACE setup, and don't ignore build warnings.

Inputs: a WORKSPACE.bazel file declaring external dependencies via http_archive, a .bazelrc for build/test/coverage flags, per-package BUILD.bazel files defining targets (ts_project, py_library, py_test, py_binary, jest_test, custom rules) with their srcs, deps, and visibility, and bazel query expressions such as deps(...), rdeps(...), or attr(tags, ...). Outputs: built target artifacts, test results (--test_output=errors), coverage reports (--combined_report=lcov), dependency graphs (bazel query ... --output=graph), and profiling data (profile.json, exec_log.json, memory.json) for identifying slow actions.

Bazel's remote caching and remote execution backends (grpcs:// cache and executor endpoints), a Build Event Service backend for CI results, and language-specific rule sets - aspect_rules_js/rules_nodejs for JavaScript/TypeScript, rules_python for Python, aspect_rules_jest for tests - plus a custom Starlark rule pattern for Docker image builds. A detailed implementation playbook lives in resources/implementation-playbook.md.

bazel query "deps(//apps/web:web)"

bazel query "rdeps(//..., //libs/utils:utils)"

Build engineers and platform teams running or migrating to Bazel in a large monorepo who need caching, remote execution, custom rules, and dependency analysis set up correctly.