vendor-update
Skill355 starsChanged 4 months agoApache-2.0View on GitHub
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.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- jctots/thinkpad-fedora-agenttheir own version, first seen Aug 15, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- jctots/thinkpad-fedora-agent★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- test/CLAUDE.mdCLAUDE.md
- bydbqlSkill
- compilingSkill
- gh-issueSkill
- gh-pull-requestSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Run the vendor-update Make target across all projects:
- Very specific: line 25
After the vendor upgrade completes, run make license-dep to update any license-related files that may have changed due to new or updated …
- Very specific: line 35
After upgrading, compare go.mod dependency versions against scripts/build/version.mk to find any tools whose library version was bumped and …
- Very specific: line 39
Read scripts/build/version.mk and go.mod in parallel.
- Very specific: line 61
If a tool version should be bumped (library changed and tool version needs to match), update scripts/build/version.mk using the Edit tool.
- Very specific: line 65
When version.mk is updated, remove the corresponding old binary from bin/:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Upgrade vendor dependencies
Run the vendor-update Make target across all projects:
make vendor-updateThis runs go get -u ./... and go mod tidy -compat=1.26 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-depThis 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

