Skip to content

fix: tokenize plugin search queries instead of matching one literal substring - #285

Open
Agnik47 wants to merge 1 commit into
agentrhq:mainfrom
Agnik47:fix/282-plugin-search-multiword
Open

fix: tokenize plugin search queries instead of matching one literal substring#285
Agnik47 wants to merge 1 commit into
agentrhq:mainfrom
Agnik47:fix/282-plugin-search-multiword

Conversation

@Agnik47

@Agnik47 Agnik47 commented Aug 11, 2026

Copy link
Copy Markdown

Description

searchCatalogPlugins tested the whole query as one literal substring of "name description", so multi-word queries missed a one-word plugin name:

$ webcmd plugin search "hacker news" -f json   # => {"plugins": [], "errors": []}
$ webcmd plugin search hackernews -f json      # => hackernews plugin
$ webcmd plugin search hacker -f json          # => hackernews plugin

This matters because skills/webcmd-usage/SKILL.md sends agents down registry filter → empty → plugin search <query> → empty → raw browser fallback, and agents naturally derive multi-word queries from the user's own words ("pull the top 5 stories from Hacker News" → hacker news). A real adapter (hackernews) exists and is invisible to the exact query an agent is most likely to try.

Fix

Strip non-alphanumeric separators from both the query and the "name description" haystack, split the query into independent tokens, and require every token to match (AND semantics) rather than testing the query as one contiguous string. This makes hacker news, hacker-news, and hackernews all match, and makes token order irrelevant (news hacker matches too), while a query like reddit news still correctly finds nothing.

I checked webcmd list -f json (mentioned in the issue as worth checking) — it filters by --tag, not a free-text query, and doesn't call searchCatalogPlugins at all, so it doesn't share this matcher and needs no change.

Fixes #282

Type of Change

  • 🐛 Bug fix
  • ✨ New feature
  • 🌐 New site adapter
  • 📝 Documentation
  • ♻️ Refactor
  • 🔧 CI / build / tooling

Checklist

  • I ran the checks relevant to this PR
  • I updated tests or docs if needed
  • I included output or screenshots when useful

Screenshots / Output

npm run typecheck and npm run build pass, generated artifacts stay byte-identical.

Reproduced the exact issue repro against the real bundled catalog, after the fix:

$ webcmd plugin search "hacker news" -f json
{
  "plugins": [
    { "name": "hackernews", "description": "Webcmd commands for hackernews", ... }
  ],
  "errors": []
}

Added a test to src/plugin-catalog.test.ts covering hacker news, hacker-news, hackernews, hacker, and reordered news hacker all matching, plus reddit news correctly matching nothing:

$ npx vitest run --project unit src/plugin-catalog.test.ts
 Test Files  1 passed (1)
      Tests  8 passed (8)

…ubstring

searchCatalogPlugins tested the whole query as a single substring of
"name description", so multi-word queries like "hacker news" missed a
one-word plugin name like hackernews even though "hacker" alone found it.

Strip non-alphanumeric separators from both sides and require each query
token to match independently, so word order and separators (space, hyphen,
concatenation) no longer matter.

Fixes agentrhq#282
@github-actions

Copy link
Copy Markdown
Contributor

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

plugin search: multi-word queries return nothing ("hacker news" misses hackernews)

1 participant