// Use when changing NativeLink JSON5 configuration, deployment examples, protobuf/service protocol surfaces, or compatibility-sensitive config behavior.
| name | nativelink-config-protocol |
| description | Use when changing NativeLink JSON5 configuration, deployment examples, protobuf/service protocol surfaces, or compatibility-sensitive config behavior. |
Use this skill when a task touches nativelink-config, JSON5 examples, deployment config, protobuf definitions, generated protocol code, or service APIs.
NativeLink config changes usually require more than editing one struct.
Check:
nativelink-config/ for config structs and serialization behavior.nativelink-config/examples/ for JSON5 examples.deployment-examples/, deploy/, kubernetes/, and templates/ for user-facing config samples.Preserve compatibility where practical:
For service or proto work, inspect both the generated API surface and the implementation layer:
nativelink-proto/ for protobuf definitions and generated interfaces.nativelink-service/ for REAPI, bytestream, BEP, worker API, and health service behavior.nativelink-util/ for shared digest/proto conversion helpers.Don't manually edit generated code unless the repository's generation workflow requires checked-in generated changes.
Start focused:
bazel test //nativelink-config/...
bazel test //nativelink-service/...
Then broaden when the change crosses service boundaries:
bazel build //:nativelink
bazel test //...
For docs or examples:
bazel build docs
bazel build nativelink-config:docs
bazel test doctests
Migrate a Bazel project from WORKSPACE to Bzlmod (MODULE.bazel). Use when a project has a WORKSPACE / WORKSPACE.bazel file but no MODULE.bazel, when the user asks to "migrate to bzlmod", "adopt MODULE.bazel", "drop WORKSPACE", "move to Bazel modules", or upgrade to Bazel 8/9 compatibility. Covers the hybrid WORKSPACE.bzlmod gradual migration, dependency translation (http_archive→bazel_dep, repo rules→use_repo_rule / module extensions, bind→alias), toolchain registration, override directives, the toolchainization pattern for rule-set authors, dual WORKSPACE/Bzlmod API design for library modules, minimum-version strategy with single_version_override, fixing Label(@computed_repo_name) patterns, and writing parameterized backwards-compatibility smoke tests.
Use when verifying NativeLink changes with Bazel, selecting focused test targets, debugging rustfmt/clippy aspect failures, or preparing a confidence report for Rust/Bazel changes.
Use when updating NativeLink Cargo dependencies, Bazel module dependencies, rules_rust pins, lock files, toolchains, or generated dependency metadata.
Use when debugging NativeLink local remote execution, remote cache/executor self-tests, BEP event ingestion, worker scheduling, CAS misses, or Bazel remote execution behavior.
Use when implementing or reviewing Rust changes in NativeLink crates, especially storage, scheduler, worker, service, config, and shared utility behavior.