Run consumer release commands through Go tools

docs/consumers/adoption.md

@@ -34,8 +34,21 @@ Go minimum. See the
 [Go tool dependency reference](https://go.dev/ref/mod#go-mod-file-tool).
 
 Run `go tool releasekit` from within the consumer module to use its selected
-version. Follow the [CLI contract](../cli.md) for commands and exit statuses,
-and the [configuration reference](../config.md) for the release profile.
+version. Go builds and caches the executable and preserves its exit status.
+A launcher invoked from that module can forward commands directly:
+
+```sh
+#!/bin/sh
+exec go tool releasekit "$@"
+```
+
+For a launcher callable from other directories, first change to its consumer
+module directory. Follow the [CLI contract](../cli.md) for commands and exit
+statuses, and the [configuration reference](../config.md) for the release profile.
+
+For consumers using vendoring, register the CLI before running `go mod vendor`
+so the vendor tree includes its dependencies. `go tool` follows Go's normal
+vendor selection.
 
 ## Go API consumers
 
@@ -89,9 +102,10 @@ Go module identity. The Go consumer minimum remains 1.26.0.
 ## CI adoption
 
 The maintained [consumer tag-delivery workflow](delivery.md#woodpecker-tag-workflows)
-supports both tool and ordinary package dependencies. It builds ReleaseKit from
-the tagged consumer's module selection, so the committed module files also
-govern CI delivery and retries. Registering the CLI as a tool is sufficient for
+supports both tool and ordinary package dependencies. It runs `go tool releasekit`
+with temporary module metadata derived from the tagged consumer's module
+selection, so the committed module files also govern CI delivery and retries.
+Registering the CLI as a tool is sufficient for
 consumers that use ReleaseKit only for maintainer commands.
 
 Upgrade the module-selected tool and workflow together. For a tag created before