Dependency review
Skill yarlson/yarstack/plugins/yarstack/skills/dependency-review
Engineering workflows and standards for Codex and Claude Code: plan, implement, test, review, and deliver repository changes.
npx -y skills add yarlson/yarstack --skill dependency-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Review dependency provenance and reproducibility without modifying them. Use when manifests, lockfiles, vendor state, generated dependency state, registries, fetched tools, or version pins change.
SKILL.md
1.7 KB, as published. Nobody here has run it
Dependency Review
Own dependency necessity, provenance, pinning, reproducibility, and generated-state consistency.
Workflow
- Confirm the changed dependency surface, comparison target, repository pinning policy, and expected update path.
- Establish the consumer and current need for each added, removed, or changed dependency or tool.
- Verify manifest, lockfile, vendor, checksum, and generated-state consistency without normalizing unrelated content.
- Check provenance, registries, Git sources, floating versions, fetched installers, lifecycle scripts, and reproducibility.
- Prefer trusted offline and non-mutating checks. Require explicit authority before network access, installation, cache mutation, lifecycle-script execution, or regeneration.
- Delegate exploitability and credentials to
security-review, CI machinery toci-review, infrastructure impact toinfra-review, and runtime compatibility torollout-readiness-review.
Report each finding with location, affected contract, evidence, consequence, smallest correction, verification, and uncertainty. State directly when no actionable finding exists. An evidenced inconclusive result is valid when tooling or provenance is unavailable.
Do not upgrade unrelated dependencies, churn an entire lockfile, add scanners, or trust committed generated code without checking its source.
Finish when each changed dependency is accounted for and residual provenance or reproducibility risk is explicit.