TL;DR: go.mod changed but vendor/modules.txt was not regenerated, so the vendored build sees a mismatch and refuses to run. Re-run go mod vendor to regenerate the vendor tree from the current go.mod. Commit the regenerated files together with the go.mod change so CI stays consistent.

```text
go: inconsistent vendoring in vendor/modules.txt
```

1. Regenerate the vendor tree: `go mod vendor`.
   Expected: the command completes and vendor/modules.txt is rewritten.
2. Review what changed: `git status` and `git diff --stat vendor/`.
   Expected: modules.txt and possibly vendored package files show the updates matching your dependency change.
3. Build in vendor mode: `go build -mod=vendor ./...`.
   Expected: the build succeeds with no inconsistency error.
4. Commit the regenerated vendor directory together with the go.mod and go.sum changes.
   Expected: a fresh checkout builds cleanly and CI, which uses vendor mode, passes.

## Use this when
- The build fails with the exact "inconsistent vendoring" message.
- A dependency was upgraded (go get, manual edit) without re-running go mod vendor.
- CI builds with -mod=vendor or GOFLAGS forces vendor mode.

## Not for this skill when
- There is no vendor directory at all; run go mod vendor once to create it, which is a setup step, not a repair.
- The error is about -mod=readonly refusing updates; that is a different flag with a different fix.
- go.sum reports checksum mismatches; the module cache or proxy is the problem, not vendoring.

## Variant phrasings
- "go inconsistent vendoring in vendor modules.txt"
- "go mod vendor after go get"
- "inconsistent vendoring after upgrading dependency"
- "go build vendor modules.txt out of date"

## Why it happens
With vendoring, Go records the exact module versions in vendor/modules.txt at the moment you run go mod vendor. Any later change to go.mod makes that recorded set stale. Builds in vendor mode compare the two and refuse to run rather than silently mixing versions, which is why the error appears instead of a wrong-version build.

## Edge cases
- Agents that bump Go dependencies must run go mod vendor in the same step as the bump, never as a follow-up.
- If vendor/ is git-ignored in your project, either commit it or stop building with -mod=vendor; a half-vendored setup breaks everyone.
- GOFLAGS=-mod=vendor in CI makes this error surface there first; reproduce it locally with the same flag.
- Go workspaces need the vendor tree regenerated for the workspace modules involved, not just the main module.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MrpUP0QOWIxL-gOVtTlGzA