reagin Explore Published Go Packages
Answer package questions from current, attributable evidence. godig is the preferred interface when its CLI or MCP operations are already available because it exposes focused pkg.go.dev queries. Direct official sources remain the fallback and the authority for ambiguous results.
Define the target
Identify:
- the package import path and containing module path;
- the requested facet: API, examples, version, dependencies, license, importers, or vulnerabilities;
- the caller's Go version and platform when build constraints matter;
- the version selected by a local repository.
For a local project, read go.mod, go.work, replace directives, and imports first. Record the selected module version before comparing it with published documentation.
Choose the interface
| Question | Best starting point |
|---|---|
| Published docs, examples, versions, licenses, importers | godig or pkg.go.dev |
Exact dependency source selected by go.mod, including replacements |
gopls or the local module cache |
| Local definitions, references, implementations, or rename impact | gopls/LSP |
| Reachable vulnerabilities in the current application | govulncheck or an equivalent workspace reachability check |
| Library comparison or adoption decision | Live package evidence followed by a separate trade-off analysis |
When godig is present, inspect godig --help and the relevant subcommand help because its command surface is versioned. Start with a compact overview and request only the needed facet. Read references/godig-operations.md for the operation map and token-efficient query patterns.
Verify with authoritative sources
Prefer, as relevant:
- pkg.go.dev or
godigresults derived from it for package documentation and published metadata; - the canonical source repository and tagged release notes for implementation and changes;
- official Go module infrastructure for version and checksum evidence;
- vuln.go.dev and Go vulnerability tooling for advisories and reachability;
- go.dev for language, toolchain, and module behavior.
Check time-sensitive facts live and include the observation date. Confirm vanity imports and semantic-import-version paths against declared module metadata.
Investigate by facet
API and examples
Pin the relevant version. Report the exact exported signature and documented behavior, including errors, concurrency guarantees, deprecations, and build constraints. Prefer a symbol-level query when one symbol answers the question; package-wide docs and examples can be much larger.
Versions and compatibility
Check major-version paths, Go and toolchain directives, release notes, platform/build tags, CGO, retractions, prereleases, and pseudo-versions. “Latest” is a fact, not automatically a recommendation.
License and provenance
Identify the license material for the exact version and link to it. Flag ambiguity, multiple licenses, generated code, forks, and replacements instead of inventing a legal conclusion.
Dependencies and importers
Distinguish direct requirements, transitive requirements, public packages importing a package, and local call sites using a symbol. Importer counts and repository popularity are context, not proof of suitability.
Vulnerabilities
Separate an advisory affecting a module version, the affected packages or symbols, and local reachability. A clean database query means no matching known advisory was returned; it is not a security guarantee.
Report compact evidence
Include only relevant rows:
| Item | Finding | Version/build context | Source | Observed |
|---|---|---|---|---|
| Identity | Package and module | Selected version | Direct official link | Date |
| API | Signature and behavior | GOOS/GOARCH if relevant | Versioned docs/source | Date |
| License | Detected material and uncertainty | Exact module version | License source | Date |
| Security | Advisory and reachability status | Exact module version | Go vulnerability source | Date |
Label inferences and unresolved facts. If neither godig nor live official sources are reachable, state what could not be verified.