Yet another Hacker News

10 points hatappo 1 day ago 8 comments

There are already many services for discovering public skills, and many ways to manage your own personal skills.

What still feels missing is the middle layer: how teams and organizations share AI agent skills, track provenance, and keep them safe to use.

Agent Skill Harbor is an OSS skill management platform for that layer. It is GitHub-native, DB-less, and serverless by design, because skills are mostly text artifacts that already fit naturally in Git.

It collects skills from GitHub repos, tracks provenance, supports governance and safety checks, and publishes a static catalog site with GitHub Actions and GitHub Pages.

Repo: https://github.com/skill-mill/agent-skill-harbor Demo: https://skill-mill.github.io/agent-skill-harbor-demo/

CharlieDigital 1 day ago | parent

I wish all of the tooling vendors would support MCP prompts because that would solve this problem and provide a very good way of delivering aggregate feeds of skills -- dynamically, even.

Codex, for example, currently does not support this[0].

Then we can just point to an MCP server and have the MCP server dynamically compose the set of skills without needing to do any syncs, git sub-modules, etc.

[0] https://github.com/openai/codex/issues/5059

stingraycharles 1 day ago | parent

Skills are not (only) just prompts, the more advanced skills have scripts or other assets as well.

CharlieDigital 1 day ago | parent

Scripts are just text; skills are just text. Scripts can be inlined with the skill. Agent can create its own temp dir and extract the script to run.

Don't overthink it; it's all just text. I want to serve the text from HTTP instead of having to deploy via `git` and sync. I want to be able to dynamically generate that text on the server based on the identity of the user, their role, what team they're in, what repo they're working on.

I don't want static skills. That users have to remember to sync and keep up to date.

mrdonbrown 1 day ago | parent

I could be wrong, but I don't think there is anything in the skills spec that prohibits a skill from having binaries? A skill may even choose to embed them to be able to run in sandboxed environments.

Agreed on skills not being static. Of course, with the way the internet works, I don't want them to be too dynamic either :)

climike 1 day ago | parent

Also worth pushing for a more standardized skills command for CLIs, similar to —help, but for (agent/human) workflows, https://cliwatch.com/blog/designing-a-cli-skills-protocol (if you ship these with your CLI, you also get versioning out of the box so to say)

hatappo 1 day ago | parent

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.

hatappo 1 day ago | parent

  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.

mrdonbrown 1 day ago | parent

Why stop at skills though? If you are trying to solve the provisioning problem for agent tools, shouldn't that also include MCP, commands, hooks, rules, etc in addition to skills?