[neuralkoi]

I'm not familiar with Skills, but looking at the repo I find the amount of decorative code/text as overkill for what amounts to just the following prompt in a bash script (yikes) executing after a commit is run:

    {"hookSpecificOutput":{"hookEventName":"PostToolUse","additionalContext":"[learning-opportunities-auto] The user just committed code. Per the learning-opportunities skill, consider whether this is a good moment to offer a learning exercise. If the committed work involved new files, schema changes, architectural decisions, refactors, or unfamiliar patterns, ask the user (one short sentence) if they'd like a 10-15 minute exercise. Do not start the exercise until they confirm. If they decline, note it — no more offers this session."}}

[alexhans]

Skills are just a good standard to describe repeatable workflows saving context through progressive disclosure, prompt sharing and, very underused feature, also bound the non deterministic parts with determism (which could be scripts).

Conceptually, you should treat them as incremental software instead of magic you grab from others [1]

The killer feature is that coding harnesses tend to have SkillBuilder agent skills so creating them becomes very easy and you can evolve them.

I recommend you build your own for your particular pain points.

Very simple example [2] showing what another user mentioned around "evals" so that you can really achieve good enough correctness for your automation.

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

- [2] https://alexhans.github.io/posts/series/evals/sketch-to-text...

[skinfaxi]

After reading your first article I'm not sure I would agree. Skills are certainly transferrable in the sense that a sufficiently narrowly-tailored skill can be applicable for others with no modification. Similar to how we grab libraries that encapsulate certain abstractions for us.

[fnordpiglet]

They’re transferable to the next agent context session because every new session is a blank slate from the agents point of view. Capturing a workflow in skills is highly useful for your own workflows that you refine over time because you don’t have to reintroduce the concepts. You can use a lot of these triggers like hooks and scripts required by the skill use to inject a fair amount of constraints and determinism, and lean on the abductive abilities of the LLM to fill in the reasoning gaps. Teams also compile libraries of skills in plugin form via marketplaces to allow a certain amount of conformity of process, procedure, etc.

This is an interesting skill plugin for me because I actually face this inverse problem a fair amount where you want to teach people about a repo and the skills associated with it so they understand the intent behind things quickly. Seeing a bunch of skill commands and behaviors doesn’t always make clear why things are the way they are. The people on the other end need context, and the rapidity with which you can create fairly complex stuff means you need a faster way than “three months of onboarding” to get people up to speed.

[alexhans]

Sorry. I'm not sure about the specific part you don't agree with. You prefer people to just use skills instead of building them?

That's fair but I think this is similar to power tools like vim, obsidian or others. There's the path of grabbing other people's workflows and not being able to modify them to really tailor the tool to your needs and there's the minimal incremental path that empowers you and gives you control all the way through. It gets you to understand the tools and you'll be able to think possibilities that match your exact problems.

I'm not dogmatic about it but I do really recommend it. You can see the transformative shift once people start "skill building" instead of "skill consuming".

Edit: The approach I mention works with non engineers/developers. So there's no different technical bar.

[saidnooneever]

most stuff in these tools is just another md file which get spliced into prompt somehow. its how llms work.. this is normal. its also why id recommend people to use claude to build a similar tool for themselve. you will spend some tokens on it and then after save like 90% token costs using your own tool... its really crazy how much less tokens and calls are needed to do meaningful work....

also you can secure/lockdown tool calls better and make the agents tasks retryable, give it failure modes etc. (not if ur laptop dies during agent work its only god and the agent who know what happened to your code.. oh no wait. the agent needs to just spend 100k tokens to remember where it was (great way to spend ur money).