Untitled topic
1–10 of 13 posts
Re: undefined
#2Codex, 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.
Re: undefined
#3I 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.…
Re: undefined
#4I 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.…
Re: undefined
#5I 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.…
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.Re: undefined
#6I 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.…
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 proven…
Re: undefined
#7I 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.…
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)
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.
Re: undefined
#8I 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.…
Skills are not (only) just prompts, the more advanced skills have scripts or other assets as well.
Re: undefined
#9I 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.…
Skills are not (only) just prompts, the more advanced skills have scripts or other assets as well.
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.