It is not really an agent package manager. It is a tool to sync agents configs. I checked out agent-resources, cool idea, maybe if lnai gains some traction I could contribut to your tool so it supports importing skills to .ai/ :)

It's great to have the option to optimize for different models, but I'm not going to on 99% of projects. And a good chunk of the agent docs are model agnostic (how to run linter, test libraries/practices). It's cool to have a way to reuse easily, even if that's copying AGENTS.md into the right places.

Totally valid take. Models might have different prompting guidelines for best results. If a developer uses one tool and wants to optimize their config as much as possible for that specific tool, LNAI is probably not for them.

However given how many tools there are and how fast each tool moves, I find myself jumping between them quite often, just to see which ones I like most or if some tool have improved since I lasted checked it. In this case LNAI is very helpful.

Agents.md is usually only a part of ai coding tool config. LNAI handles syncing additional configs like skills, sub-dir rules, mcps, permissions to every tool. Additionally, even thought AGENTS.md is popular, not every tool supports that standard.

Looks very similar. That's good - diversity and more options are good.

But ... as the author and maintainer of Ruler I can tell you that I don't use it and I don't recommend using it (or this new tool).

In almost all cases it isn't necessary anymore - most agents support AGENTS.md (or at least a hack like `@AGENTS.md` in CLAUDE.md), and Agent Skills are the best way to customise agents and are available everywhere now.

There are some corner cases where using a tool like Ruler may still make sense, but if in doubt, you probably don't need it.

At a glance there are a few differences: - LNAI additionally supports permissions - The way rules for sub-directories are defined is different. Ruler defines rules for sub-directories in the sub-directories themselves under ‘.ruler/‘. LNAI defines rules for sub-directories by using front matter ‘paths’ property and storing all rules under ‘.ai/rules’ - ruler supports more tools (I will continue maintaining and improving lnai to also support more tools / configs) - lnai supports per tool overrides in ‘.ai/.{codex/claude/etc.}’ for more granular control while keeping a single source of truth - ruler is a more mature package

For files that don't need transformation (AGENTS.md, skills, most rules), LNAI creates symlinks. .claude/CLAUDE.md → ../.ai/AGENTS.md. Edit the source, all tools see it immediately.

For transformed files (Cursor's .mdc frontmatter, GEMINI.md sub-directory rules), you re-run lnai sync. LNAI maintains a manifest tracking of every generated file with content hashes, so it knows what changed and cleans up orphans automatically.

So it's not really "sync once", it's "symlink for instant propagation, regenerate-on-demand for transforms." The manifest ensures LNAI always knows its downstream state.

This system can also break down if you create new skills/rules in the specific tool directories (.claude, .codex, etc.) but that is against LNAI's philosophy. If you need per-tool overrides you put them in `.ai/.{claude/codex/etc.}` sub-directories and LNAI manages them for you.

Yes, the tool takes that into account and transforms mcps/permissions/rules to different tool formats. Sadly some tools might not support fine-grained permissions (e.g. Codex) in which case a warning will be displayed but everything else will get transformed/symlinked. Additionally you can put per-tool overrides in ‘.ai/{codex/claude/cursor/etc.}/‘ if needed and lnai will automatically symlink those overrides to respective tools.

For simple config files like AGENTS.md/skills that is true. But some configs like MCPs/Permissions/Rules require transformations per tool. On lnai's per-tool docs pages (e.g. https://lnai.sh/tools/codex/) I have documented what transforms are needed per-tool. There are quite a few of them.