/vendor-update
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade", "bump dependencies", "update packages", or asks to run the `vendor-update` Make target. This skill also
$ npx -y skills add apache/skywalking-banyandb --skill vendor-update --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/vendor-update
Context preview
The summary Claude sees to decide when to auto-load this skill.
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade", "bump dependencies", "update packages", or asks to run the `vendor-update` Make target. This skill also
SKILL.md
vendor-update.SKILL.mdname: vendor-update
description: >
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the
user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade",
"bump dependencies", "update packages", or asks to run the `vendor-update` Make target.
This skill also checks `scripts/build/version.mk` after upgrading to see if any
tracked tool versions need updating too, and removes stale binaries from `bin/`
when versions change.
compatibility: go, make
Upgrade vendor dependencies
Run the vendor-update Make target across all projects:
make vendor-update
This runs `go get -u ./...` and `go mod tidy -compat=1.25` in each project directory (ui, banyand, bydbctl, mcp, fodc/agent, fodc/proxy, pkg, test).
Update license dependencies
After the vendor upgrade completes, run `make license-dep` to update any license-related files that may have changed due to new or updated dependencies:
make license-dep
This ensures license headers and dependency license files stay in sync with the upgraded vendors.
Check for tool version drift
After upgrading, compare `go.mod` dependency versions against `scripts/build/version.mk` to find any tools whose library version was bumped and may need their tool version updated.
Version mapping
Read `scripts/build/version.mk` and `go.mod` in parallel. For each tool version variable, check if the corresponding library in go.mod was upgraded:
| version.mk variable | Binary | go.mod package | |---|---|---| | `BUF_VERSION` | `bin/buf` | `github.com/bufbuild/buf` (if present) | | `PROTOC_GEN_GO_VERSION` | `bin/protoc-gen-go` | `google.golang.org/protobuf` | | `PROTOC_GEN_GO_GRPC_VERSION` | `bin/protoc-gen-go-grpc` | `google.golang.org/grpc` | | `PROTOC_GEN_DOC_VERSION` | `bin/protoc-gen-doc` | `github.com/pseudomuto/protoc-gen-doc` (if present) | | `GRPC_GATEWAY_VERSION` | `bin/protoc-gen-grpc-gateway` | `github.com/grpc-ecosystem/grpc-gateway/v2` | | `PROTOC_GEN_VALIDATE_VERSION` | `bin/protoc-gen-validate` | `github.com/envoyproxy/protoc-gen-validate` | | `GOLANGCI_LINT_VERSION` | `bin/golangci-lint` | (no go.mod entry — only in version.mk) | | `REVIVE_VERSION` | `bin/revive` | (no go.mod entry — only in version.mk) | | `LICENSE_EYE_VERSION` | `bin/license-eye` | (no go.mod entry — only in version.mk) | | `MOCKGEN_VERSION` | `bin/mockgen` | `go.uber.org/mock` | | `GINKGO_VERSION` | `bin/ginkgo` | `github.com/onsi/ginkgo/v2` | | `GOVULNCHECK_VERSION` | `bin/govulncheck` | `golang.org/x/vuln` | | `BPF2GO_VERSION` | (used in bpf2go.mk) | `github.com/cilium/ebpf` |
**Only update version.mk if the library version in go.mod has changed and the tool version should follow.** Many tools (golangci-lint, revive, license-eye) are not in go.mod — their versions only change when explicitly updated in version.mk, not from `make vendor-update`.
Update version.mk if needed
If a tool version should be bumped (library changed and tool version needs to match), update `scripts/build/version.mk` using the Edit tool. Keep the format exactly — e.g., `PROTOC_GEN_GO_VERSION := v1.36.11`.
Remove stale binaries
When version.mk is updated, remove the corresponding old binary from `bin/`:
rm bin/<binary-name>
This ensures the next build/install of that tool fetches the correct new version.
Read more
name: vendor-update description: > Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade", "bump dependencies", "update packages", or asks to run the `vendor-update` Make target. This skill also checks `scripts/build/version.mk` after upgrading to see if any tracked tool versions need updating too, and removes stale binaries from `bin/` when versions change. compatibility: go, make
Upgrade vendor dependencies
Run the vendor-update Make target across all projects:
make vendor-update
This runs `go get -u ./...` and `go mod tidy -compat=1.25` in each project directory (ui, banyand, bydbctl, mcp, fodc/agent, fodc/proxy, pkg, test).
Update license dependencies
After the vendor upgrade completes, run `make license-dep` to update any license-related files that may have changed due to new or updated dependencies:
make license-dep
This ensures license headers and dependency license files stay in sync with the upgraded vendors.
Check for tool version drift
After upgrading, compare `go.mod` dependency versions against `scripts/build/version.mk` to find any tools whose library version was bumped and may need their tool version updated.
Version mapping
Read `scripts/build/version.mk` and `go.mod` in parallel. For each tool version variable, check if the corresponding library in go.mod was upgraded:
| version.mk variable | Binary | go.mod package | |---|---|---| | `BUF_VERSION` | `bin/buf` | `github.com/bufbuild/buf` (if present) | | `PROTOC_GEN_GO_VERSION` | `bin/protoc-gen-go` | `google.golang.org/protobuf` | | `PROTOC_GEN_GO_GRPC_VERSION` | `bin/protoc-gen-go-grpc` | `google.golang.org/grpc` | | `PROTOC_GEN_DOC_VERSION` | `bin/protoc-gen-doc` | `github.com/pseudomuto/protoc-gen-doc` (if present) | | `GRPC_GATEWAY_VERSION` | `bin/protoc-gen-grpc-gateway` | `github.com/grpc-ecosystem/grpc-gateway/v2` | | `PROTOC_GEN_VALIDATE_VERSION` | `bin/protoc-gen-validate` | `github.com/envoyproxy/protoc-gen-validate` | | `GOLANGCI_LINT_VERSION` | `bin/golangci-lint` | (no go.mod entry — only in version.mk) | | `REVIVE_VERSION` | `bin/revive` | (no go.mod entry — only in version.mk) | | `LICENSE_EYE_VERSION` | `bin/license-eye` | (no go.mod entry — only in version.mk) | | `MOCKGEN_VERSION` | `bin/mockgen` | `go.uber.org/mock` | | `GINKGO_VERSION` | `bin/ginkgo` | `github.com/onsi/ginkgo/v2` | | `GOVULNCHECK_VERSION` | `bin/govulncheck` | `golang.org/x/vuln` | | `BPF2GO_VERSION` | (used in bpf2go.mk) | `github.com/cilium/ebpf` |
**Only update version.mk if the library version in go.mod has changed and the tool version should follow.** Many tools (golangci-lint, revive, license-eye) are not in go.mod — their versions only change when explicitly updated in version.mk, not from `make vendor-update`.
Update version.mk if needed
If a tool version should be bumped (library changed and tool version needs to match), update `scripts/build/version.mk` using the Edit tool. Keep the format exactly — e.g., `PROTOC_GEN_GO_VERSION := v1.36.11`.
Remove stale binaries
When version.mk is updated, remove the corresponding old binary from `bin/`:
rm bin/<binary-name>
This ensures the next build/install of that tool fetches the correct new version.
BanyanDB, as an observability database, aims to ingest, analyze and store Metrics, Tracing and Logging data. It's designed to handle observability data generated by observability platform and APM system, like Apache SkyWalking etc.
Repo: apache/skywalking-banyandb
Other skills on banyandb-bydbql.
- /bydbql
Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query BanyanDB, translate natural language to BydbQL, inspect BanyanDB schema or data, validate BydbQL, or fetch raw BanyanDB
Open skill - /compiling
Compile and build the SkyWalking BanyanDB project. Use when the user asks to compile, build, or generate code for this project.
Open skill - /gh-pull-request
Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request.
Open skill

