Live data from Hacker News

Ask HN: How do you manage skills files?

news.ycombinator.com

41–50 of 306 posts

Re: Ask HN: How do you manage skills files?

#42
The main problem I encountered around this is that skills need to be edited across projects and across team members in a controlled way. Git is of course required for this but is not enough so I built a tool to do just that:

https://github.com/genged/capshelf

Using capshelf I manage my skills across projects. When I start a new project I can just:

$ capshelf add security-review

From the skill repo.

And if I create a new skill I can promote it to the repo so everyone can install it:

$ capshelf promote security-review

It pins the skill content hash so there are no unexpected edits that can break your flow. It also supports MCP configs and agent configs.

Re: Ask HN: How do you manage skills files?

#43
- I don't find skills, I create them

- Keep them organised in software repos that you install with symlinks for all coding harnesses that you have. Progressive disclosure based on the frontmatter does the rest.

- I make sure they work with AI evals. Think of them like integration tests to prove behaviour. They're useful to optimize your flows. I try to make my skills be mostly a translation between natural language and good small fast tools that they call.

- I change them as a new problem arises. Not just because.

Skills can't be eaten by model capabilities if skills represent a workflow that is custom to my team or my person.

I wrote about a good mental model in the past:

https://alexhans.github.io/posts/series/evals/building-agent...

Re: Ask HN: How do you manage skills files?

#47
post #29

I don't use any skills, what kinds of skills are people finding most useful? For general tasks, the model seems perfectly capable of figuring out things itself, for project or environment specific tasks, I just put that information in the readme or agents.md file.

I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.

Isn’t that what the agents.md in your project is for?

Re: Ask HN: How do you manage skills files?

#48

We keep the skills in a repo, where an agentic workflow runs biweekly to check if their content drifted compared to the docs and opens PRs if they did. The repo is also a Claude plugin. The biggest problem is keeping skills up to date across users, so I developed a small Go binary that takes care of that across harnesses.

That's very cool. How does the binary keep skills updated across users?

Re: Ask HN: How do you manage skills files?

#49
post #29

Earlier quoted context omitted.

I make skills for «this is how I like to do things in this company / project». Query test database, git branch names, commit message style, which cloud things can be inspected like logs etc. I don’t see the point in trying to teach the models things that is in the documentation of git, python, what have you. They already know.

Isn’t that what the agents.md in your project is for?

I try to keep agents/Claude.md as tiny as possible. With high level "truths" that don't change. Stack used, invariants, file structure, and some scripts.

Skills are more for things you do often. I run mutation tests, type check,linting,etc. I _could_ just prompt and copy/paste the same prompt each time I need to, or I can just run /tests.

I also have skills for specialized tasks I need every once in a while, like a ux skill, a text skill optimized for xyz, etc.

Re: Ask HN: How do you manage skills files?

#50

I don't use any skills, what kinds of skills are people finding most useful? For general tasks, the model seems perfectly capable of figuring out things itself, for project or environment specific tasks, I just put that information in the readme or agents.md file.

Your agents.md is a good place for high level facts, but if you have something that requires a lot of info to explain (ie: if there is a complex build process, testing patterns, things like that), loading up your agents.md for every request may be a bad idea. Offloading that information to a skill ensures it's only included in the context if you're actually using it.
Post reply on HN