Supply chain pinning
Skill 26zl/universal-agent-skills/skills/supply-chain-pinning
Add dependencies deliberately by justifying each new one, pinning versions or commits, respecting lockfiles, and never executing unpinned remote code. Use when adding or updating packages, container images, GitHub Actions, install scripts, or vendored code; do not use to block upgrades the user explicitly requested.From its SKILL.md
npx -y skills add 26zl/universal-agent-skills --skill supply-chain-pinningAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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 file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
1.5 KB, 237 tokens by cl100k_base, as published. Nobody here has run it
Supply Chain Pinning
Every dependency is code you now ship; adopt it deliberately or not at all.
Rules
- Before adding a dependency, state what it is needed for and why the standard library or an existing dependency does not cover it.
- Pin what you adopt: exact versions in manifests where the ecosystem supports it, full commit hashes for Git sources and GitHub Actions, digests for container images.
- Never pipe remote scripts into a shell and never fetch install code from a mutable reference; when a script install is unavoidable, download, review, and execute it from disk.
- Respect lockfiles: change them through the ecosystem's own tool, never by hand, and never delete one to make an install pass.
- Read what changed before adopting an update; a major version bump or a maintainer change is a review event, not a routine edit.
- Prefer maintained dependencies with compatible licenses over unmaintained or trivially replaceable packages.
Boundaries
- Explicitly requested upgrades proceed; this skill shapes how they happen, not whether.
- Ecosystems without real pinning support get the strictest available constraint plus a note about the residual risk.
What ships with it: 1 file
206 B alongside SKILL.md
agents/
- openai.yaml206 B
Gives 0 of the 12 instructions most dependency audit skills give in 237 tokens
Counted across 162 of the 192 authors here whose files we hold, read 2026-09-06
- Verify the gh tool is installed before startingin 10 of 162, across 6 files
- Find git repositories for all direct dependenciesin 9 of 162, across 5 files
- Evaluate every dependency against the risk criteriain 9 of 162, across 5 files
- Normalize repository names to full URLsin 9 of 162, across 5 files
- Query exact star and issue counts using ghin 9 of 162, across 5 files
- Ask the user to install gh if missingin 7 of 162, across 3 files
- Omit low-risk dependencies from the reportin 7 of 162, across 3 files
- Run the full test suite after each changein 7 of 162
- Flag dependencies matching any risk criterion with clear reasonsin 6 of 162, across 2 files
- Commit lockfiles and pin exact dependency versionsin 6 of 162, across 5 files
- Detect package managers from manifest filesin 6 of 162
- Review the changelogs for breaking changesin 5 of 162, across 2 files
Said here and by no other author read
- Download, review, and execute unavoidable install scripts from disk
- Change lockfiles only through the ecosystem's own tool
- Read what changed before adopting an update
- Treat major bumps and maintainer changes as review events
- Prefer maintained dependencies with compatible licenses
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.