[Skills] Improve installed status in search, add source subtitle, and auto-refresh on install#27443
[Skills] Improve installed status in search, add source subtitle, and auto-refresh on install#27443raulgg wants to merge 1 commit intoraycast:mainfrom
Conversation
…ist, and refresh on install
|
Thank you for your contribution! 🎉 🔔 @keito4 @DaleSeo @pernielsentikaer you might want to have a look. You can use this guide to learn how to check out the Pull Request locally in order to test it. 📋 Quick checkout commandsBRANCH="skills/update-installed-detail-in-search"
FORK_URL="https://github.com/raulgg/raycast-extensions.git"
EXTENSION_NAME="skills"
REPO_NAME="raycast-extensions"
git clone -n --depth=1 --filter=tree:0 -b $BRANCH $FORK_URL
cd $REPO_NAME
git sparse-checkout set --no-cone "extensions/$EXTENSION_NAME"
git checkout
cd "extensions/$EXTENSION_NAME"
npm install && npm run devWe're currently experiencing a high volume of incoming requests. As a result, the initial review may take up to 10-15 business days. |
|
@keito4 @DaleSeo I'm keeping this as a draft for now, but it's ready for you to review. I would love to hear your thoughts and feedback on the change I'm proposing before publishing the PR. The skills CLI has a behavior I dislike when adding skills from different sources that share the same name: it replaces the old skill with the new one without any warning. This can be unexpected, and it also feels surprising in the extension. After the recent change to display the "Installed" badge in search results, I thought it would be helpful to clarify the potential outcomes when trying to install a skill that reuses the name of a currently installed one from a different source. I would appreciate any thoughts on this proposed change, whether you think it's excessive or if you have any suggestions for improvements. |
|
Thanks for sharing your proposal, @raulgg! I agree with the overall direction. I'm glad you're coloring the icons of installed skills green. I was planning to make that change to align with how outdated skills are displayed in the other command. The piece I'd push back on is squeezing the sources next the skill names, which could lead to truncation as shown in the screenshot. Skill names are what users primarily scan for, so I think ellipsing them could create more problems than the duplicate-name confusion we're trying to solve. Collisions are the minority case and can usually be avoided by typing more search terms. Could we explore options that preserve the full skill name? I'm happy to discuss the trade-offs. Just want to make sure we don't fix one DX issue by introducing another. @keito4 Please feel free to chime in if you have any other thoughts. |
|
Thank you for your feedback @DaleSeo! This is the type of feedback I was hoping for. You're right that truncating the skill name is far from ideal, and we must avoid that; so I'll try to find an alternative. I was really hoping to be able to show the source in the list since it's also the default behavior of the CLI when using
Unfortunately, Raycast does not currently provide a method to ensure that the title is not truncated, at least to my knowledge. The only compromise I can think of at this moment is to display the subtitle only when the details are hidden. However, the challenge with this approach is that we still lack a mechanism to persist the mode across sessions (we can discuss wether to add this in a later iteration is worth it or not). For my personal workflow, I would prefer to have the subtitle consistently displayed alongside the skill name, even if that means to have the detail hidden by default, as this would help me identify which skill I wish to navigate to, whether by scrolling through the list or by typing further in the search. However, until we can agree on a more effective solution, I am happy with this solution of displaying it only in full width mode, as I agree that truncating the skill name is a significant drawback.
What do you think? |




Description
The problem this addresses is that "Search Skills" command previously treated installed skills as installed by
skillIdonly. That meant multiple search results could show as "Installed" even when they were technically different skills from different sources and only shared the same name. In thereact-doctorexample below, several distinct skills appeared installed while only one was.Current:

Proposed change:

This is risky because the Skills CLI currently overwrites installs for skills with the same name without asking the user to confirm that they understand they are replacing a different source. The UX changes in this PR try to make that behavior visible in the extension and guide users through install decisions before they accidentally replace an existing skill.
Changes include:
owner/repo, as the subtitle in both "Search Skills" and "Manage Skills" commands to distinct skill results from different sources at first glance..skill-lock.json.skillIdis installed from a different source, show a warning indicator, and offer a "Replace Installed Skill" action to better represent the outcome of the action.withSkillActionfor more consistent confirmations, toasts, and failure handling.Checklist
npm run buildand tested this distribution build in Raycastassetsfolder are used by the extension itselfREADMEare located outside the metadata folder if they were not generated with our metadata tool