Allow more flexibility in where gh skill finds skills

[oWretch]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Apps

Body

I have started to try out the new gh skill CLI interface to help manage the skills I use. One of my common set of skills is around managing Terraform, and HashiCopr publishes some skills for this in hashicorp/agent-skills. However the gh skill command expects to find the skills in a certain set of locations which is understandable.

It would be nice to be able to specify a path to the skill in addition to the repo/skill name. For example, since the Terraform skills are in the terraform/code-generation/skills folder, it would be nice to either be able to install them with a path, e.g.

gh skill install hashicorp/agent-skills terraform/code-generation/skills/terraform-style-guide

or to have a path property which could be supplied and the standard search rules applied e.g.

gh skill install hashicorp/agent-skills terraform-style-guide --repo-path terraform/code-generation

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[oWretch]

Ironically, the microsoft/skills repo can't be used for the same reason, as the skills are in the .github/skills folder

[SamMorrowDrums]

Thanks for flagging

[SamMorrowDrums]

@oWretch thanks for the suggestion, supporting a custom remote path feels like a reasonable idea, I replied to a similar issue here: cli/cli#13197 (comment)

I think it's important for the ecosystem to share skills as a publisher specifically, and that only consumers should be using the install directories.

Attribution matters: this is the crux of the problem, you want the version and install location of the skill to be attached to the repo that publishes it, and want to the repo specific installed version to have that information attached to it (which we add to the front-matter) so that you can clone the repo and still get access to updates etc.

If there is no way to distinguish between publishers and consumers, that's a problem that we need to be generally opinionated on for this tool to work.

I agree that enabling the possibility of installing things at least with a path flag feels like a good compromise. Will think on it.

[oWretch]

Thanks @SamMorrowDrums

If someone points at a skill that has the metadata for a different repo, could/should the cli surface that to the user and recommend (or inform) pulling from the upstream repo? This would be similar to just copying it around.

Another option could be to actively block pulling from common consumer paths (e.g. .agents, .copilot, .claude, or any dot folder) though that would encourage copying without the metadata being added.

And hopefully over time if this gains traction publishers will move their skills to the expected locations to make installation easier. Though that then raises the question of redirects, which could be a security risk…

[oWretch]

See also cli/cli#13197