-
-
Notifications
You must be signed in to change notification settings - Fork 26
Claude skills generation #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8d775ca to
f34d8ed
Compare
| else | ||
| igniter.args.positional.packages || [] | ||
| cond do | ||
| # For claude-skills, manually parse from argv since Igniter misparses positional args as flags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing the disagreement with argument/options in generating Claude skills vs the current usage_rules.sync task makes me think perhaps this would make sense as its own task instead. mix usage_rules.sync_claude_skills.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think that makes sense, there is a non trivial overlap in capabilities though.
| # Ignore HTML comments when finding the first line | ||
| description = | ||
| content | ||
| |> String.split("\n") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
talked about it in discord, but for this to make sense I think it should be some text suited to this purpose, either the package description plus some static text, or configured by the library providing these rules.
|
I did this manually the other day using the create-skill skill and the usage rules files and was thinking it would be great to have this built in. Glad you all are on it. What are your thoughts on usage rules being skills instead of linked or included in the AGENTS.md? |
|
I'm not sold that it's the best way vs just one big-ass context file in all honesty 😆 But I don't mind making it an option in usage_rules. I think maybe we should consider making this an entirely separate task though. mix usage_rules.gen.skill <skill_name> <pkg1, pkg2, pkg3>which could then create or update a skill with the usage rules for some list of packages. The reason I say that is that I think it makes sense for skills to be curated. Alternatively, we can support some metadata by package authors of what "skill" their package should be included in? Not sure TBH. |
|
I like the separate mix task. Also experimenting and not sold either way, but having easy ways to keep things syncd from a single source is very nice. |
|
Yeah, reflecting I agree on a separate mix task. Closing this PR, open to another PR that implements this as a separate task! |
|
Totally agree with separate mix task, also another mix task could be generating Claude plugins. Thinking about both of these things are actually quite model specific (Claude in this case) and so the mix tasks should probably mention this. No doubt other frontier model providers will emulate this in a similar but slightly different way, and it will also evolve over time too (probably relatively quickly). |
Experiment to generate Claude skills from Usage Rules. For an example of the output check out this repo https://github.com/joshprice/claude-skills-from-usage-rules