Auto-installing Claude skill should be opt-in, not automatic

[andreialecu]

Hey team,

I noticed that version 16.0.12 automatically installs a Claude skill, and I think this approach might cause some issues down the line.

The problem

Auto-installing the skill globally doesn't work well for project-based workflows. Here's why:

First, not everyone wants Claude skills installed globally. Some of us prefer keeping skills at the project level to maintain better control over dependencies and configurations.

Second, different projects might end up using different versions of ax-llm over time. When that happens, an auto-installed global skill could cause compatibility issues in legacy projects that are stuck on older versions.

Suggested solution

Make the Claude skill installation opt-in through a CLI command instead. Something like:

yarn ax-llm-cli --install-claude-skill --local

This would let developers choose when and where to install the skill, and it could be documented in the README as an optional setup step.

Additional context

I get that auto-installing makes the initial setup easier, but I think giving developers control over this installation is worth the extra step. Projects evolve at different paces, and forced global installations can create friction when managing multiple projects with different requirements.

What do you think?

[dosco]

Not against this will give it more thought this week

[dosco]

Installing the skill globally was a bug I've moved it to a local install. I'm treating it as part of the code so when someone chooses to install ax in his project the skill is part of the whole package. Making it optional will not help it's adoption.

[andreialecu]

Sounds good. Local install is fine.

[andreialecu]

One thing to note after reviewing the latest commit is that I'm not sure that the way you're finding .claude is correct.

Needs to be tested in a project with (yarn/bun/pnpm) workspaces for example. process.cwd() may not be correct. I remember needing https://www.npmjs.com/package/workspace-root in the past, but I'm not sure if it's still needed.

[andreialecu]

https://www.npmjs.com/package/resolve-workspace-root

This one seems more recent.

—

Still, I think you should think deeply about whether you want this by default rather than opt in.

It might still end up in the wrong place, and could be annoying users if it does.

Also, what about people who don't use Claude?

[dosco]

Thanks I'll take a look and improve the search for .claude if needed. I'd rather not make it optional but would love to understand your thoughts here more.

Yes, if there are bugs in we find the folder those can be fixed .claude/skills is now a standard and is used by cursor as well I looked into this. I was told Antigravity will be adopting it as well. With llm coding now growing at such a fast rate it'll be a big miss not to include default skills.

[andreialecu]

Thanks, I'll take a look and improve the search for .claude if needed. I'd rather not make it optional but would love to understand your thoughts here more.

I don't have a strong opinion on @ax-llm in this context, as I value this package.

However, if I were discovering it for the first time, installing files outside the package directory would be unexpected. A few concerns:

1. Leftover files. If someone tests ax-llm temporarily (or an LLM does in an automated test), those skills persist after uninstall
2. Security implications. As more packages adopt this pattern, there's a risk of buggy or malicious skills being installed with elevated access
3. Precedent. This goes beyond typical package behavior

I think this should be opt-in rather than automatic.

Longer term, it would be better if agents could discover skills within package directories through a standard approach. LLMs already parse well-structured README.md files and JSDoc comments effectively. Since JSDoc was just added to ax-llm, discoverability should have improved significantly.

Rather than each package installing global files, packages could expose skills through documentation that agents discover at runtime - whether through enhanced README sections, dedicated AI.md files, or whatever standard emerges.

This would address the security and cleanup concerns while keeping skills accessible.

[andreialecu]

Another concern is that you'll need to keep maintaining it as standards change. This seems outside the scope of what you're trying to achieve with ax-llm. For example, I'm not sure if Codex uses the .claude directory.

I found an attempt here to address this idea as well: https://github.com/onmax/npm-agentskills

Personally, I also usually disable scripts - so I would still need a way to opt-in to installing it.

The final decision is up to you.

Check discussion here as well: agentskills/agentskills#81

[dosco]

All great points maybe making it optional is the way to go. Thanks