fix: auto-switch to relevance sort when search query is entered

[oolong-tea-2026]

Problem

When users search for skills on the /skills page, results are always sorted by downloads instead of relevance, making the vector search scoring (semantic similarity + lexical boost) effectively useless.

Root cause

The beforeLoad redirect in skills/index.tsx injects sort=downloads whenever no sort param is present. Since all entry points (Browse Skills button, Header Skills link, Header Search link) arrive without a sort param, the URL always becomes ?sort=downloads.

When the user then types a search query, the sort computation in useSkillsBrowseModel.ts checks:

const sort = search.sort === "relevance" && !hasQuery
  ? "downloads"
  : (search.sort ?? (hasQuery ? "relevance" : "downloads"))

Because search.sort is already "downloads" (not undefined), the ?? fallback to "relevance" never triggers.

Impact

100% of normal-path users are affected. The only way to get relevance-based search results is to manually select "relevance" from the sort dropdown, which most users never do.

This means skills with high semantic relevance to a query but low download counts are buried behind popular but less relevant results.

Reproduction

1. Open an incognito/private browser window
2. Go to https://clawhub.ai
3. Click "Browse skills"
4. Observe URL has sort=downloads
5. Type a search query (e.g., a specific skill slug)
6. Observe sort dropdown still shows "downloads", not "relevance"

Fix

When hasQuery is true, always use relevance sort. When query is cleared, fall back to the URL sort param or downloads.

This is a one-line logic change in useSkillsBrowseModel.ts. The sort dropdown still allows users to manually override to any sort order during search.

Before / After

Scenario	Before	After
User types search query	Sort stays as downloads	Sort switches to relevance
User clears search query	Sort stays as downloads	Sort reverts to downloads
User manually selects sort during search	Respected	Respected (overridden by relevance on next query change)

[vercel]

@oolong-tea-2026 is attempting to deploy a commit to the Amantus Machina Team on Vercel.

A member of the Team first needs to authorize it.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4851ba24fb

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve manual sort override for active queries

When q is non-empty, useSkillsBrowseModel now hardcodes sort to relevance, so onSortChange can still write search.sort to the URL but the selected sort is never actually applied while searching. This regresses behavior for users who intentionally switch to downloads/stars/etc. during a search (the dropdown choice is effectively ignored until the query is cleared).

Useful? React with 👍 / 👎.

[greptile-apps]

Greptile Summary

This PR fixes a real UX bug where search results on the /skills page were always sorted by downloads instead of relevance, rendering the semantic search scoring useless for the vast majority of users.

The one-line logic change in useSkillsBrowseModel.ts correctly auto-switches to 'relevance' sort when a query is active. However, the implementation overshoots: by unconditionally returning 'relevance' whenever hasQuery is true, it silently ignores any value the user may have chosen from the sort dropdown. The sort dropdown remains visually interactive (it writes to the URL via onSortChange) but has no effect on the computed sort value as long as a query is present — a functional regression from the previous behaviour.

Key points:

• The core bug fix (auto-relevance on search) is correct and well-motivated
• The stated "After" behaviour ("User manually selects sort during search → Respected") does not match what the code actually delivers
• The beforeLoad injection of sort=downloads on every cold page load (mentioned in the root-cause section of the PR description) remains unaddressed and would still interfere with any approach relying on search.sort being undefined to signal "no explicit user preference"

Confidence Score: 3/5

• Safe to merge for the primary goal, but introduces a secondary regression where the sort dropdown becomes non-functional during an active search.
• The fix is a small, targeted change that solves a well-described and impactful bug. The regression (sort dropdown ignored while a query is active) is a real functional issue, though limited to users who explicitly try to override sort during search. The discrepancy between the PR's stated "After" behaviour and the actual implementation warrants a revision before merging.
• src/routes/skills/-useSkillsBrowseModel.ts — specifically the sort computation on lines 51–53 and its interaction with onSortChange.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/routes/skills/-useSkillsBrowseModel.ts
Line: 51-53

Comment:
**Manual sort override silently ignored while searching**

The new logic unconditionally returns `'relevance'` whenever `hasQuery` is true, meaning the sort dropdown becomes non-functional during an active search. When a user selects `'downloads'` or `'stars'` from the dropdown while searching, `onSortChange` writes `search.sort` to the URL, but the computed `sort` always evaluates to `'relevance'` regardless — the actual sort used never matches the user's selection.

The PR description's "After" column states the manual sort selection is **"Respected"**, but the code contradicts this. The original code correctly threaded `search.sort` through for any manually-chosen value while a query was active; only the implicit default was broken.

To preserve the ability to manually override the sort during search, the auto-switch to relevance should only apply when `search.sort` has not been explicitly set by the user (i.e. when it is `undefined`). The `beforeLoad` injection of `sort=downloads` into the URL on cold page loads would still bypass this intent, which is a related but separate root-cause issue worth addressing alongside this fix.

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: 4851ba2}

[greptile-apps]

Manual sort override silently ignored while searching

The new logic unconditionally returns 'relevance' whenever hasQuery is true, meaning the sort dropdown becomes non-functional during an active search. When a user selects 'downloads' or 'stars' from the dropdown while searching, onSortChange writes search.sort to the URL, but the computed sort always evaluates to 'relevance' regardless — the actual sort used never matches the user's selection.

The PR description's "After" column states the manual sort selection is "Respected", but the code contradicts this. The original code correctly threaded search.sort through for any manually-chosen value while a query was active; only the implicit default was broken.

To preserve the ability to manually override the sort during search, the auto-switch to relevance should only apply when search.sort has not been explicitly set by the user (i.e. when it is undefined). The beforeLoad injection of sort=downloads into the URL on cold page loads would still bypass this intent, which is a related but separate root-cause issue worth addressing alongside this fix.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/routes/skills/-useSkillsBrowseModel.ts
Line: 51-53

Comment:
**Manual sort override silently ignored while searching**

The new logic unconditionally returns `'relevance'` whenever `hasQuery` is true, meaning the sort dropdown becomes non-functional during an active search. When a user selects `'downloads'` or `'stars'` from the dropdown while searching, `onSortChange` writes `search.sort` to the URL, but the computed `sort` always evaluates to `'relevance'` regardless — the actual sort used never matches the user's selection.

The PR description's "After" column states the manual sort selection is **"Respected"**, but the code contradicts this. The original code correctly threaded `search.sort` through for any manually-chosen value while a query was active; only the implicit default was broken.

To preserve the ability to manually override the sort during search, the auto-switch to relevance should only apply when `search.sort` has not been explicitly set by the user (i.e. when it is `undefined`). The `beforeLoad` injection of `sort=downloads` into the URL on cold page loads would still bypass this intent, which is a related but separate root-cause issue worth addressing alongside this fix.

How can I resolve this? If you propose a fix, please make it concise.

[oolong-tea-2026]

Good catch! Fixed in fdf9654. The new approach: onQueryChange clears the URL sort param when entering a search query (so search.sort ?? 'relevance' kicks in as default), but manual dropdown selection writes to search.sort and takes precedence. This preserves user overrides while fixing the original bug where beforeLoad-injected sort=downloads persisted through search.