메뉴
Use after editing any Bazel file — BUILD.bazel, MODULE.bazel (including bazel/rust.MODULE.bazel), or a .bzl file — to validate the change without paying for a full build, and to auto-format it.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when upgrading a Rust crate / third-party dependency to a new version — especially non-trivial bumps where the new version removes previously-deprecated APIs, moves modules into separate crates, renames items, or otherwise has a broad blast radius across many crates. Covers reading the changelog, picking the version deliberately, splitting the migration into aspects, and migrating incrementally.
Use when you need to run a command (build, test, tool) inside the IC dev container via ./ci/container/container-run.sh — including on a host that has Docker but not podman (set CONTAINER_RUNTIME=docker) — or when you need to keep a namespace.so devbox awake during long-running work.
Use this when asked to fix flaky bazel tests.
Use when you need to run a Bazel build or test outside DFINITY's internal infrastructure — i.e. without access to the internal remote cache / remote downloader (bazel-remote.idx.dfinity.network), e.g. on a personal machine, in a sandbox, or for a reproducibility check. Two ways: --config=local, or bypassing the workspace bazelrc.
Use this when asked to fix a Bazel build reproducibility / determinism issue — a target whose outputs differ between builds (e.g. across machines, users, or checkout locations), typically because something bakes an absolute build path or a timestamp into an artifact.
Guide the governance backend canister upgrade process — pick RC commit, determine targets, create proposal texts, submit proposals, create forum posts, schedule votes, and update changelogs.
| name | check-bazel-files |
| description | Use after editing any Bazel file — BUILD.bazel, MODULE.bazel (including bazel/rust.MODULE.bazel), or a .bzl file — to validate the change without paying for a full build, and to auto-format it. |
Two fast checks after editing BUILD.bazel, MODULE.bazel, or .bzl files,
run from the repository root (cd "$(git rev-parse --show-toplevel)"):
--nobuildbazel build //... --nobuild
This loads and analyzes the entire workspace — catching BUILD.bazel/.bzl
syntax errors, bad load()s, broken labels, and analysis-phase failures across
every package — without actually building anything. It's much cheaper than a
real build and covers the whole repo rather than just the directly affected
targets, which matters because a bad MODULE.bazel/.bzl change (e.g. a
macro used repo-wide) can break packages far from the file you touched.
Fix any errors it reports.
bazel run //:buildifier
Auto-formats and lint-fixes every BUILD.bazel/.bzl file in place (see the
buildifier target in bazel/BUILD.bazel, aliased at //:buildifier). To
only check without writing changes (e.g. to see a diff first), use
bazel run //:buildifier.check instead.
Cargo.toml
([workspace.dependencies]) and bazel/rust.MODULE.bazel (as a
crate.spec(...)), so mirror the change across both (matching package,
version, features), then repin per the Repin step in .claude/CLAUDE.md
(./bin/bazel-pin.sh) — --nobuild alone won't catch a stale
@crate_index.bazel isn't available or reachable in your current environment, see the
run-in-dev-container and build-without-dfinity-infra skills.