One idea I'm toying with right now: My company has some internal nodejs libraries, some of which are quite large (think: codegen API library, thousands of types). When a new version is published: task claude code to distill the entire library down to a skill, then bundle that in with the npm package. Then when the package is installed, postinstall a script that copies the skill from the dependency to the parent project that's doing the installing.

I'm still getting this set up, so I'm not sure yet if it'll lead to better outcomes. I'd say, there's reason to believe it might, but there's also reasons to believe it won't.

If the library is like 50,000 lines of code long, thousands of types, hundreds of helper functions, CC could just look into the node_modules folder and bundle all of this into its context. But, this might not be feasible, or be expensive; so the SKILL.md distills things down to help it get a high level understanding faster.

However, the flip side of that is: What if its too general? What if CC needs specific implementation details about one specific function? Is this actually better than CC engaging a two-step process of (1) looking at node_modules/my-lib/index.ts or README.md, get that high level understanding, then (2) look at node_modules/my-lib/specificFunction.ts to get the specific intel it needs? What value did the SKILL.md actually convey?

My feeling is that this concept of "human-specified context-specific skills" would convey the most value in situations where the model itself is constrained. E.g. you're working with a smaller open source model that doesn't have as comprehensive intrinsic knowledge of some library's surface, or doesn't have the context windows of larger models. But, for the larger models... its probably just better to rely on in-built model knowledge and code-as-context.

Maybe the skill could have references to the code. Like if everything else fails it can look at the implementation.

Intuitively it feels like if you need to look at the implementation to understand the library then the library is probably not well documented/structured.

I think the ability to look into the code should exist but shouldn't be necessary for the majority of use cases