Hacker News Reader

Comment by hatappo | Hacker News Reader

10 pointshatappo8 comments

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

  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.

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)

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.

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?

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

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.

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 :)

Reply on news.ycombinator.com