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.
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)
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.
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?
6 comments
[ 2.8 ms ] story [ 19.9 ms ] threadCodex, 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