One thing that bothered me is that Skills usually sit outside normal package-manager protections.
Package ecosystems are increasingly using ideas like pnpm’s `minimumReleaseAge` and uv’s `--exclude-newer` to avoid pulling in artifacts that are too new. But Skills often aren’t package-managed at all, even
though they may include helper scripts, downloaded artifacts, and even binaries.
Given recent supply-chain incidents like the axios compromise, and research like Snyk’s ToxicSkills report, that felt like a real gap.
So I added a cooldown mechanism based on the Git tree hash of the skill directory.
The CLI now resolves a Skill from Git history, treats the skill directory tree as the release unit, and only installs/updates to a tree that is older than a configured minimum age. If the latest one is too new,
it falls back to the newest eligible older tree.
I’d be especially interested in feedback on whether “directory tree hash” seems like the right trust/version boundary for non-package-managed AI artifacts.
I think TanStack Intent is quite close to that direction.
Packaging skills with libraries/CLIs and letting agents discover them from installed packages makes a lot of sense. I see Harbor as addressing a different layer on top
of that: organizational collection, cataloging, provenance, governance, and safety.
Yes, I agree that MCP-based prompt/skill delivery would be a very interesting direction.
If tooling vendors broadly supported MCP prompts, an MCP server could become a dynamic distribution layer for team-managed skills, which would remove a lot of sync-oriented workflow.
My current assumption is that we still need something Git-native today because:
- skills are mostly authored and reviewed in Git
- teams need provenance and governance around them
- tool support for MCP prompt delivery is still incomplete
So I see Harbor more as a practical system for the current ecosystem, not necessarily the final shape.
https://github.com/skill-mill/agent-skill-porter
One thing that bothered me is that Skills usually sit outside normal package-manager protections.
Package ecosystems are increasingly using ideas like pnpm’s `minimumReleaseAge` and uv’s `--exclude-newer` to avoid pulling in artifacts that are too new. But Skills often aren’t package-managed at all, even though they may include helper scripts, downloaded artifacts, and even binaries.
Given recent supply-chain incidents like the axios compromise, and research like Snyk’s ToxicSkills report, that felt like a real gap.
So I added a cooldown mechanism based on the Git tree hash of the skill directory.
The CLI now resolves a Skill from Git history, treats the skill directory tree as the release unit, and only installs/updates to a tree that is older than a configured minimum age. If the latest one is too new, it falls back to the newest eligible older tree.
This is implemented as `--min-age` for add/download/update. ex. `sk add https://github.com/remotion-dev/skills --min-age 30`
I’d be especially interested in feedback on whether “directory tree hash” seems like the right trust/version boundary for non-package-managed AI artifacts.
reply