Hey — I'm from Gingiris, a team that builds growth playbooks for open-source developer tools. We focus on projects that already have something real working and help them grow the community around it.
Your README mentions skills.sh as a marketplace where users can install skills from directly within Agentfiles — but that feature is currently described in one bullet point with no surrounding context about what's actually available or how to publish there. That's a buried loop.
Two concrete things worth considering:
-
The 13-tool support matrix is a retention argument, not just a feature list. Claude Code, Cursor, Codex, Windsurf, Copilot, Amp, OpenCode — the reason this matters to a developer is that their tool stack will change, and Agentfiles means they don't lose their accumulated skills when it does. That point is implicit in your table but never stated. Adding even one sentence making that explicit ("your skills travel with you across tools") would change how developers evaluate whether to invest time building skills at all.
-
skills.sh could be a two-way growth channel. Right now Agentfiles consumes from it. If you created a skillkit publish flow (or even just a contributing guide that feeds skills back upstream), users who build something useful have a path to share it. That creates the kind of external artifact that shows up in search and brings new users back to Agentfiles as the tool that manages those skills.
We have a playbook for exactly this kind of open-source cold-start / community growth pattern: https://github.com/Gingiris/gingiris-opensource. More tooling at https://gingiris.github.io/growth-tools/ if useful.
Not pushing anything — just thought these were worth raising given what's already in place.
Hey — I'm from Gingiris, a team that builds growth playbooks for open-source developer tools. We focus on projects that already have something real working and help them grow the community around it.
Your README mentions skills.sh as a marketplace where users can install skills from directly within Agentfiles — but that feature is currently described in one bullet point with no surrounding context about what's actually available or how to publish there. That's a buried loop.
Two concrete things worth considering:
The 13-tool support matrix is a retention argument, not just a feature list. Claude Code, Cursor, Codex, Windsurf, Copilot, Amp, OpenCode — the reason this matters to a developer is that their tool stack will change, and Agentfiles means they don't lose their accumulated skills when it does. That point is implicit in your table but never stated. Adding even one sentence making that explicit ("your skills travel with you across tools") would change how developers evaluate whether to invest time building skills at all.
skills.sh could be a two-way growth channel. Right now Agentfiles consumes from it. If you created a
skillkit publishflow (or even just a contributing guide that feeds skills back upstream), users who build something useful have a path to share it. That creates the kind of external artifact that shows up in search and brings new users back to Agentfiles as the tool that manages those skills.We have a playbook for exactly this kind of open-source cold-start / community growth pattern: https://github.com/Gingiris/gingiris-opensource. More tooling at https://gingiris.github.io/growth-tools/ if useful.
Not pushing anything — just thought these were worth raising given what's already in place.