chachachainsaw

“I haven't had great success making Claude Code work with local Ollama/Quen.”

What’s been the biggest blocker for you?

I use omnigent with claude code and codex. I also built a tool (https://frontmatter.news) to help me figure out what similarities and differences there are between tools so my agents behave the same way across tools.

Definitely. Especially since those standards are fairly aligned across lots of tools. The other cool thing is a lot of desktop clients like Claude Cowork and ChatGPT Desktop also speak plugins, so hooking up marketplaces help with further distribution outside of technical teams.

FWIW I work on AI enablement in my day job for both our build org and the broader company and we’ve found success with using marketplaces for distribution.

I also built a free tool that diffs a lot of agent configs to help me keep current on changes.

Here’s the main page, but you can checkout the marketplace and plugin entries if you’re interested!

https://frontmatter.news

Most guidance I’ve read, and experienced success with, is keeping a lean agents.md file and building out a tree of docs or skills that an agent can navigate via progressive disclosure.

How do you think about using these vs using something like plugins + plugin marketplaces to distribute skills that ship natively in a lot of tools?

Have you seen mattpocock’s skills? I know they are hecka popular with people I work with.

Tracking skill usage like this is really smart, stealing this!

I’ve been keeping all skills in .agents/skills and symlinking .claude/skills, this way I can use them across both claude code and codex. One of the not so straight forward things is knowing what frontmatter overlaps, or subtle config differences exist for skills between tools, and making sure to take that into account.

I wrote a free tool to constantly diff the agent configs for a handful of tools I use. If interested you can check it out at https://frontmatter.news

I’m a heavy user of wisprflow for speech to text and prefer html output for richer understanding. Unfortunately I don’t use a text to speech with a CLI, but want to follow this thread because I’m interested in seeing what’s available!

100%. Finding the right hook is important though, especially because CC gives you so many. For my setup I use multiple coding agents and so I use frontmatter.news to compare hooks across agents so I get the same behaviour.

I mentioned on the main thread, but thought it would be topical here too. Claude Code ships LSP support but only if packaged within a plugin. So there are hoops you have to jump through to get it rather than getting it out of the box. But it might be long term more reliable than ad hoc fixes?

Claude Code ships LSP support, but only as part of a plugin. I think they’re currently the only vendor to fully support it.

One of the things I struggled with for a while was diffing the configs between tools when switching over and keeping them all straight. I recently built a free directory I’ve been hacking on to continually diff coding agents docs and source code to illustrate the differences.

Happy to share if you think it’ll add value.

Came here to say this. Output styles help a lot in cutting down the fluff.

I use a lot of agent hooks to force deterministic guardrails in the moment for faster feedback loops, like someone else mentioned. Others like pre-commit hooks and CI checks are still great for things like enforcing conventional commits, linting, etc.

What framework do you use for generating migrations? I can help share an example of what it might look like to write a hook for it. Or even your top 3 pain points.

Some of the configs are fairly similar, and if you bundle in a plugin they can be distributed without much ceremony. Something you can do for forcing cli migration generation is to write a pretool hook.

Here’s an example of shared hooks.

https://frontmatter.news/kinds/hook

This website also has markdown versions of pages and references source docs so you can point your agent to the page and ask it to crawl to the docs pages to reference the hook json definition.

Nice write-up!

I’ve moved a lot of my prose based guardrails into agent supported hooks, pre-commit hooks and CI checks. I’ve found this deterministic back pressure helps coding agents more consistently figure out for themselves when they’re doing things out of band.

I’m fully on letting agents write all code, no longer doing autocomplete. I switch between Claude Code and Codex mostly, although found Cursor’s cloud agents a nicer experience.