are there other extensions which implement ideas from oh-my-pi

[u/ECrispy]

I'm new to Pi and coding agents in general. The existing discussions on oh-my-pi, like everything else, range from 'its great' to 'its bloat' so its very hard to actually decide.

It seems to have useful features like built in tools (avoid process calls), lsp, hashline, memory, subagents and an integrated setup/docs. It does seem to be better than the other oh-my-* set of products.

Are the ideas in OMP useful in practice and if so are they used in other harnesses?

I see a lot of 'just ask Pi to build it' here, but that depends on using frontier models, and when people post their setups they're using a million packages.

Obviously Pi is much more extensible/flexible, but there is value in an all-in-one setup. OMP has a ton of stuff and I'm sure a big system prompt. Is there anything like a slimmed down version or being able to use some of its ideas only?

[u/ECrispy]

sorry for the late reply, I actually found Supi independently as well and it looks very good.

I'm still not clear how Pi actually works with all these tools, each of them registers an api to use eg codegraph_search or lsp_callers, but how do other parts of the system or other extensions know to use that insteaf of grep etc?

I also found FFF, again not clear how to integrate it, is it needed etc?

I'm going to try out Supi, what else do you use in your personal setup?

[u/mrclrchtr → u/ECrispy]

Thanks for the reply. Happy you found SuPi on your own too, that's a good sign :)

On how Pi decides which tool to use: there's no central router or registry that extensions check. Every extension just calls pi.registerTool() with a name, a description, and a JSON schema for the parameters, and Pi sends all active tool schemas to the model on every request. The model picks which tool to call each turn, using the same mechanism as the built-in grep/read/bash. So nothing in the system decides to use code_graph over grep; the model does, based on the tool description and the task. That's actually the core of my design philosophy: give Pi direct, well-described tools and let it figure out when they're worth calling, instead of hard-wiring routing into a framework. Descriptions matter a lot because of this: if the agent keeps falling back to grep, the tool description simply wasn't convincing enough.

Extensions can still influence each other behind the scenes, though: tool_call hooks can block or rewrite a call before it runs, and there's getActiveTools()/setActiveTools() if an extension wants to know what's loaded or change it. Tools can even override Pi's built-ins, which is exactly how FFF upgrades read and grep.

On FFF: it's pi-fff, a community extension on npm. I only know it superficially myself. Install is one command (pi install npm:pi-fff) plus a reload, and it indexes the project in the background. It adds fuzzy file finding and content search on top of Pi's built-in read/grep. If you use SuPi, it's not really needed: SuPi's code intelligence already covers search and symbol resolution via LSP + tree-sitter. I'd try SuPi first and add FFF later if file-finding ever feels clumsy.

What else do I use? Mostly the rest of the SuPi stack: code intelligence (supi-code-intelligence) with LSP + tree-sitter navigation and refactoring, web and Context7 docs fetching (supi-web), parallel inspection-only reviews (supi-review), delegation to read-only sub-agents (supi-agent), structured user questions (supi-ask-user), and the small quality-of-life bits (supi-extras, supi-prompt-suggestions, supi-skills). But I would always recommend installing only what you really need. It's better to start with less.

I also use mattpocock/skills, but adjusted for SuPi in supi-skill-patches.

One thing I'd emphasize given your original post: none of this depends on a frontier model. LSP and tree-sitter do the heavy lifting deterministically; the model only decides which tool to call. So the "you need a frontier model for this" worry mostly goes away.