Vet a Candidate Dependency

Evaluate a named package before adopting, replacing, or dropping it. Use current registry, published-artifact, and maintainer evidence. Return a decision with limits; do not modify the project's dependency manifests or install a package into its environment.

Route precisely

• Use when the decision is whether a specific library can satisfy this project's protocol, schema, API, runtime, or maintenance needs.
• Use code-review for a diff that happens to change dependencies; invoke this deeper vetting only when adoption or replacement is the question.
• Use a security audit for a known vulnerability in an already adopted package. Do not turn an ordinary API question into an adoption review.

Fix the required contract

1. Read repository instructions, manifests, lockfiles, and relevant specification or integration code. Write the required version, protocol revision, runtime range, and observable behavior as exact values. If the project has no fixed contract, state the assumption that drives the comparison.
2. Resolve the package through registry or module metadata to the published artifact and declared source repository. Verify tags, subdirectories, forks, and redirects before attributing repository activity to the artifact. If the source repository cannot be established, mark maintenance evidence unknown rather than substituting a search result.
3. Check the exact published version against the required contract. Prefer source code, package metadata, generated API surfaces, and a small isolated probe over README claims. If a search finds nothing, verify that the searched release is indexed or inspect the artifact directly before claiming absence.

Go modules, when applicable

For Go candidates, resolve the module path, package subdirectory, exact version, required Go version, and applicable major-version suffix. Inspect go.mod, go.sum, go.work, and replace/exclude/retract directives when relevant. A local fork selected by replace is not the published artifact that downstream consumers resolve; describe both explicitly. Check the selected module graph rather than assuming requested direct versions are the entire build. Distinguish checksum integrity, known advisories, affected build conditions, and vulnerable-symbol reachability. Use installed lookup tools only as optional evidence sources; official module/package metadata is a fallback, not a reason to install godig or register a hosted MCP server. Do not run go get or go mod tidy as part of read-only vetting.

These module-specific considerations adapt Samber's dependency-management and package-lookup guidance, under the bundled LICENSE.samber-cc-skills-golang.

Measure maintenance and fit

Inspect recent releases, issue and pull-request handling, compatibility work, and the project's own upgrade constraints. Distinguish an inactive maintainer from a quiet mature project; stars and last-push timestamps alone do not settle maintenance. Check whether support for the required version is released, pending in an unanswered PR, or absent. Record dates and links because these facts change.

When a representative behavior can be tested safely, probe it in an isolated temporary environment using the published artifact and a fixture derived from the project's contract. Do not run install scripts or arbitrary package code in the working checkout. If execution is unsafe, unavailable, or costly, mark behavior unverified and give the exact probe needed. Record declared license and provenance; flag compatibility questions for legal review rather than inventing a legal verdict.

Decide

Return ADOPT, ADOPT_WITH_RISK, REJECT, or INSUFFICIENT_EVIDENCE. Support the verdict with the required contract, tested artifact version, observed behavior, maintenance evidence, and a named fallback if support stops. An unresolved license or security gate required by the project prevents an unconditional ADOPT; identify the review needed without making up a legal or security conclusion. Separate verified facts from inference and unknowns. Do not recommend a package merely because it is popular or actively released, and do not claim a compatibility probe passed unless it was run.