Summary
tobira already tracks per-command usage, efficiency gaps (graph.efficiency_gaps()), and category-level friction (motion/edit/search/window/fold/mark/macro). This issue proposes extending that signal outward: periodically cross-reference the user's observed friction against the broader Neovim plugin ecosystem (awesome-neovim / store.nvim's 6,200+ plugin database) and surface a small number of concrete, personalized plugin recommendations — not just built-in command suggestions.
Example: a user who repeatedly does <C-w>s/<C-w>v followed by manual window navigation, with heavy gt/gT tab-switching, is exhibiting a recognizable "managing too many windows/tabs manually" shape. Today tobira can at most nudge toward built-in commands for this; it has no way to say "a plugin like smart-splits.nvim or harpoon.nvim would remove this friction entirely."
Why this needs an LLM (not a hand-written rule table)
Matching a structured behavioral signal against an unstructured, constantly-changing catalog of 6,000+ plugin descriptions is a semantic retrieval/reasoning problem, not a fixed lookup. A hardcoded mapping table would need continuous manual maintenance as the plugin ecosystem grows and shifts — the same problem tobira avoided for its own 155-command registry by keeping it hand-curated and small.
What's already out there (checked to avoid duplicating)
- dotfyle.com: recommends plugins by cross-config popularity/co-occurrence ("users with a similar setup also install X") — not based on any individual's actual editing behavior.
- store.nvim (6,200+ plugin browsable database): manual search/filter by name/tags/author/popularity — no behavior-driven recommendation.
Neither reasons from your own observed friction. This looks like open ground.
Open design questions (not yet decided — hence Design review)
- Plugin data source: self-maintained snapshot vs. crawling awesome-neovim vs. reusing store.nvim's crawler data (would need their buy-in).
- Must stay strictly opt-in and low-frequency (e.g. a
:TobiraRecommend command, or a once-a-month check at most) — this would be tobira's first feature requiring an external API call and a network round-trip, which conflicts with the "fully passive, zero config, zero cost by default" positioning in the README. Needs to be very clearly separated from the default experience.
- Privacy: what aggregated summary (not raw keystrokes) leaves the machine, and how it's presented to the user before any call is made.
- Cost: who pays for the LLM call — bring-your-own-key like some AI plugins, or a hosted free tier, or skip entirely if this can't be made cheap/optional enough.
Relevant files
lua/tobira/core/graph.lua (existing efficiency-gap / category aggregation to build the summary from)- New module, likely opt-in and isolated from core (e.g.
lua/tobira/core/recommend.lua)
Summary
tobira already tracks per-command usage, efficiency gaps (
graph.efficiency_gaps()), and category-level friction (motion/edit/search/window/fold/mark/macro). This issue proposes extending that signal outward: periodically cross-reference the user's observed friction against the broader Neovim plugin ecosystem (awesome-neovim / store.nvim's 6,200+ plugin database) and surface a small number of concrete, personalized plugin recommendations — not just built-in command suggestions.Example: a user who repeatedly does
<C-w>s/<C-w>vfollowed by manual window navigation, with heavygt/gTtab-switching, is exhibiting a recognizable "managing too many windows/tabs manually" shape. Today tobira can at most nudge toward built-in commands for this; it has no way to say "a plugin like smart-splits.nvim or harpoon.nvim would remove this friction entirely."Why this needs an LLM (not a hand-written rule table)
Matching a structured behavioral signal against an unstructured, constantly-changing catalog of 6,000+ plugin descriptions is a semantic retrieval/reasoning problem, not a fixed lookup. A hardcoded mapping table would need continuous manual maintenance as the plugin ecosystem grows and shifts — the same problem tobira avoided for its own 155-command registry by keeping it hand-curated and small.
What's already out there (checked to avoid duplicating)
Neither reasons from your own observed friction. This looks like open ground.
Open design questions (not yet decided — hence Design review)
:TobiraRecommendcommand, or a once-a-month check at most) — this would be tobira's first feature requiring an external API call and a network round-trip, which conflicts with the "fully passive, zero config, zero cost by default" positioning in the README. Needs to be very clearly separated from the default experience.Relevant files
lua/tobira/core/graph.lua(existing efficiency-gap / category aggregation to build the summary from)lua/tobira/core/recommend.lua)