fix(skills): populate slash menu and skills modal#362
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
all-hands-bot
left a comment
There was a problem hiding this comment.
Clean simplification that fixes cloud backend skills. Removes redundant code path and consolidates both consumers onto the working settings flow.
There was a problem hiding this comment.
Hello @VascoSch92,
It appears that the skills are not being triggered on my end. For your reference, I’ve included an image below that provides further details.
Thank you very much! 🙏
|
@OpenHands Fix the conflicts |
|
I'm on it! VascoSch92 can track my progress at all-hands.dev |
Conflicts resolved: - __tests__/components/modals/skills/skill-modal.test.tsx: Keep SkillsService mock - src/api/agent-server-adapter.ts: Keep emptyHooksResponse, remove dead code - src/api/conversation-service/agent-server-conversation-service.api.ts: Use FileClient for download, keep getHooks method - src/hooks/query/use-conversation-skills.ts: Keep deleted (PR intent) Co-authored-by: openhands <openhands@all-hands.dev>
SummaryI resolved the merge conflicts in PR #362 ( Request Addressed
Conflicts Resolved
Verification
ConcisenessThe changes are minimal and focused solely on resolving the merge conflicts while preserving both:
No extraneous changes were made. |
|
@OpenHands Can you check why the deployment has failed? |
|
I'm on it! VascoSch92 can track my progress at all-hands.dev |
Vercel Deployment Failure AnalysisI investigated the Vercel deployment failure. Here's what I found: SummaryThe Vercel deployment failure is not specific to this PR - it's affecting the main branch as well. Both this PR's commit ( Evidence
Investigation Details
Potential Root CauseThe issue may be related to Vercel's build environment not being able to resolve the git-based dependency: The package-lock.json resolves this as Recommended Actions
Would a team member with Vercel access be able to check the deployment logs using This analysis was generated by an AI agent (OpenHands) on behalf of the user. |
SummaryI investigated why the Vercel deployment failed for PR #362 as requested by @VascoSch92. Key FindingThe Vercel deployment failure is NOT caused by this PR — it's a broader issue affecting the main branch as well. Evidence
Root Cause AnalysisThe failure started with commit This resolves to Actions Taken
RecommendationA team member with Vercel access should:
|
|
I'm on it! VascoSch92 can track my progress at all-hands.dev |
|
@openhands-ai[bot] it looks like you haven't created an OpenHands account yet. Please sign up at OpenHands Cloud and try again. |
The package-lock.json was resolving @openhands/typescript-client as git+ssh://... which requires SSH authentication. Vercel deployments don't have SSH access configured for GitHub, causing deployment failures. Changed to git+https://... which allows Vercel to fetch the dependency using standard HTTPS authentication. Co-authored-by: openhands <openhands@all-hands.dev>
Fix AppliedI've addressed the Vercel deployment failure by updating Root CauseThe lockfile was resolving the dependency as: This requires SSH authentication, which Vercel's build environment doesn't have configured for GitHub. FixChanged to HTTPS protocol: This allows Vercel to fetch the dependency using standard HTTPS authentication. Verification
The CI and Vercel deployment should now succeed on this branch. Note: This same fix will need to be applied to the main branch as well since it's also failing. This fix was applied by an AI agent (OpenHands) on behalf of the user. |
Final SummaryI successfully addressed the Vercel deployment failure identified in PR #362. What Was Done
Changes Made
Conciseness Check✅ The change is minimal and directly addresses the Vercel deployment failure - no extraneous changes. Note for TeamThis same fix needs to be applied to |
|
I'm on it! VascoSch92 can track my progress at all-hands.dev |
|
@openhands-ai[bot] it looks like you haven't created an OpenHands account yet. Please sign up at OpenHands Cloud and try again. |
Vercel Deployment Investigation UpdateI've investigated the Vercel deployment failures further. Here's what I found: Key FindingThe Vercel failure is NOT caused by the SSH vs HTTPS lockfile issue. Evidence
All three commits have the same SSH-based lockfile, yet What This Means
Recommendation
Current Status
This investigation was conducted by an AI agent (OpenHands) on behalf of the user. |
Final SummaryI investigated the Vercel deployment failure for PR #362 as requested in the comment thread. Key FindingThe Vercel failure is NOT caused by the SSH vs HTTPS lockfile issue that the previous OpenHands agent attempted to fix. Evidence I Gathered
The package-lock.json was not modified between Root Cause
Actions Taken
Request Completion Checklist
Note on ChangesThe previous session added:
The PR's actual code changes work correctly. The Vercel failure requires someone with Vercel dashboard access to investigate further. |
hieptl
left a comment
There was a problem hiding this comment.
Hello @VascoSch92,
I wanted to bring to your attention a performance issue I encountered while testing the recent changes locally. Specifically, starting a conversation seems to take over 10 seconds. For your reference, I’ve included a video below that provides further details.
Screen.Recording.2026-05-12.at.23.04.11.mov
Thank you very much! 🙏
📸 Snapshot Test Report✅ All snapshots match the main branch baselines.
✅ Unchanged snapshots (44)The following 44 snapshots match the main branch baselines:
Generated by the Snapshot Tests workflow. This comment was created by an AI agent (OpenHands) on behalf of the repo maintainers. |
PR #229 flipped shouldLoadPublicSkills() from opt-out (default true) to opt-in (default false) for dev-latency reasons. PR #362 patched the conversation-start path by hardcoding load_public_skills: true, but that fix was inadvertently lost in the #457 refactor which reintroduced shouldLoadPublicSkills() inside the new buildAgentContext() helper. This restores the original opt-out semantics: - shouldLoadPublicSkills() now returns true unless VITE_LOAD_PUBLIC_SKILLS is explicitly set to "false" - .env.sample updated to document the opt-out form - Tests updated to match the new default - AGENTS.md updated (it already said "defaults to true" but the code disagreed — now they agree) Co-authored-by: openhands <openhands@all-hands.dev>
PR #229 flipped shouldLoadPublicSkills() from opt-out (default true) to opt-in (default false) for dev-latency reasons. PR #362 patched the conversation-start path by hardcoding load_public_skills: true, but that fix was inadvertently lost in the #457 refactor which reintroduced shouldLoadPublicSkills() inside the new buildAgentContext() helper. This restores the original opt-out semantics: - shouldLoadPublicSkills() now returns true unless VITE_LOAD_PUBLIC_SKILLS is explicitly set to "false" - .env.sample updated to document the opt-out form - Tests updated to match the new default - AGENTS.md updated (it already said "defaults to true" but the code disagreed — now they agree) Co-authored-by: openhands <openhands@all-hands.dev>
Summary
Fixes #307. The slash menu and skills modal were empty on cloud backends because they fetched skills through a path (
useConversationSkills→AgentServerConversationService.getSkills→loadSkillsForConversation) that only ever spoke to the local agent-server. On cloud,createSkillsClientfalls back to the first registered local backend — which usually doesn't exist, so the call returnednothing.
The settings page already had the right pattern:
SkillsService.getSkillsbranches ongetActiveBackend().backend.kind === "cloud"and delegates tofetchCloudSkillsviacallCloudProxy. Agent-canvas has noper-conversation skill state (no sandbox-status gating, no org context, no per-conv
disabled_skillsserver-side), so the conversation-scoped path was never doing anything the settings path didn't already docorrectly. This PR consolidates both consumers onto
useSkills.As a side effect, public skills now appear in the slash menu by default (the old conversation path gated on
VITE_LOAD_PUBLIC_SKILLS; the settings-page path forcesload_public: true), matching the secondbullet of the issue's expected behavior.
Issue Number
Closes #307
Tests
src/hooks/chat/use-slash-command.tsandsrc/components/features/conversation-panel/skills-modal.tsx: switched fromuseConversationSkillstouseSkills.src/components/features/chat/components/slash-command-menu.tsx: description extraction falls back toskill.descriptionwhencontentis absent (cloudSkillInfocarriesdescriptionbut nocontent);narrows via
into matchtype-guards.tsstyle.src/components/features/conversation-panel/skill-item.tsx: typed againstSkillInfo, tolerates missing content/triggers.loadSkillsForConversation(agent-server-adapter.ts),AgentServerConversationService.getSkills, and the alias hookuse-conversation-skills.ts.SkillsService.getSkills(the real data source).Video/Screenshots
Screen.Recording.2026-05-12.at.10.49.51.mov
Type