6 ms·

My approach is different. Skills I write mostly use Python to save on the agent needing to run its own loops. I use these loops to monitor the CI build and PR

My approach is different. Skills I write mostly use Python to save on the agent needing to run its own loops. I use these loops to monitor the CI build and PR approvals rather than having the agent poll, and even Opus gets the commands wrong enough to make it worth it. Last week I wired up a skill for the agent to share screenshots in PRs via specific S3 buckets and AWS CLIs. Again, the agents guess at the right commands often enough to make it worth being explicit. Sure these could have gone in CLAUDE.md, but not every agent needs the context. And at the company level, I can push skills to everyone’s Claude via the Teams function, they don’t need to edit configs or even know what a skill is.

mhh__ 9d ago
small behaviours are fine, yes, what i was referring to was people making "foobar api skill" with just a bad compression of the foobar docs in a .md
sleepybrett 9d ago
the problem with that, that i'm seeing is just the sheer proliferation of internal skills. There are now so many that I can't see how they can possibly remain maintained. It feels like at the project/product/middle management layer this type of 'big pile of skills to do some very specific task' is very popular. I think this is probably for a few reasons. I think the largest factor is that these task management items are really just like .. calling a few different apis and slapping it through some jinja to post to github and create a jira ticket.. whatever. For an engineer, we can knock that out over coffee. But for this middle management layer, not a lot of them have the will or the skills to pop open the ide and code themselves a tool. Until the advent of skills that is. So I think they are a bit drunk with power. Which yaknow we'll see. The skills are starting to become the documentation for these types of things as well as a way to automate it. This is great, but this type of 'documentation' is exactly the type of thing that goes non-updated for years in some dark corner of confluence. So I suspect the little used skills are going to fall to 'context rot'. As an engineer, I keep all those skills in one very specific claude project and keep that largely separate from any given claude session that's helping me design a feature.
- breckenedge 6d ago
  Yea I definitely keep engineering skills and org skills separate.

mhh__ 9d ago

small behaviours are fine, yes, what i was referring to was people making "foobar api skill" with just a bad compression of the foobar docs in a .md

sleepybrett 9d ago

the problem with that, that i'm seeing is just the sheer proliferation of internal skills. There are now so many that I can't see how they can possibly remain maintained. It feels like at the project/product/middle management layer this type of 'big pile of skills to do some very specific task' is very popular. I think this is probably for a few reasons. I think the largest factor is that these task management items are really just like .. calling a few different apis and slapping it through some jinja to post to github and create a jira ticket.. whatever. For an engineer, we can knock that out over coffee. But for this middle management layer, not a lot of them have the will or the skills to pop open the ide and code themselves a tool. Until the advent of skills that is. So I think they are a bit drunk with power. Which yaknow we'll see. The skills are starting to become the documentation for these types of things as well as a way to automate it. This is great, but this type of 'documentation' is exactly the type of thing that goes non-updated for years in some dark corner of confluence. So I suspect the little used skills are going to fall to 'context rot'. As an engineer, I keep all those skills in one very specific claude project and keep that largely separate from any given claude session that's helping me design a feature.

breckenedge 6d ago
Yea I definitely keep engineering skills and org skills separate.