[c5huracan]

The bottleneck isn't "how do I define my agent." It's "how do agents find the right tool for their task."

I run a search service that 110+ agents use. They don't browse catalogs or read specs. They describe what they need ("MCP server for Postgres") and expect results back immediately. The definition format matters far less than whether the description is good and whether something can find it.

SKILL.md, AGENTS.md, SOUL.md, they're all converging on the same idea. That's fine. But the portability win only kicks in once there's a discovery layer that can index all of them. Without that, these files are just README.md with a new name.

[Shreyaskapale]

Maintainer here. Quick clarification on what we're actually solving — GitAgent is about portability. Build your agent once, run it on Claude Code, LangChain, CrewAI, OpenAI — without rewriting it. The repo IS the agent. You're raising a different problem: runtime discovery, agents finding the right tool mid-task. That's valid and it's a harder problem. We have registry.gitagent.sh for human-time discovery — browse, find, clone. But agent-time discovery is a layer we haven't fully cracked yet. Where they connect: your search service needs consistent, structured descriptions to index well. That's exactly what SKILL.md is — a standard way for every agent to describe what it can do. Without that consistency you're parsing free-form text and hoping. You're running 110+ agents on this — you probably have sharper opinions on what good discovery looks like than most. What would you build on top of a consistent spec like this?

[Shreyaskapale]

you asked for it i solved it :) introducing skillflows - https://x.com/Shreyaskapale/status/2033218826004029525