3 ms·

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 s

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 https://github.com/openai/codex/issues/5059

stingraycharles 7mo ago
Skills are not (only) just prompts, the more advanced skills have scripts or other assets as well.
- hatappo 7mo ago
  [dead]
- CharlieDigital 7mo ago
  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 7mo ago
    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 7mo ago
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 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 7mo ago
  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 7mo ago
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.
- deleted 7mo ago
  [deleted]
mrdonbrown 7mo ago
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?
- hatappo 7mo ago
  [dead]

stingraycharles 7mo ago

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

hatappo 7mo ago
[dead]
CharlieDigital 7mo ago
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 7mo ago
  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 7mo ago

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 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 7mo ago
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 7mo ago

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.

deleted 7mo ago
[deleted]

mrdonbrown 7mo ago

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?

hatappo 7mo ago
[dead]