Expose project provider skills in chat#3982
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 887c718. Configure here.
ApprovabilityVerdict: Needs human review This PR introduces a new feature exposing project-aware provider skills in chat, including new RPC endpoints, skill discovery for Grok/Codex providers, and prompt rewriting logic. The scope and cross-cutting nature of these changes warrants human review. You can customize Macroscope's approvability policy. Learn more. |

Summary
listSkillscapability, RPC, client query, and composer pipelinegrok --cwd <cwd> inspect --json$skillreferences to Grok native/skillsyntax only at the ACP boundary while retaining$skillin stored and rendered messagesThis supersedes #3901. The replacement generalizes the project-skill feature across Codex and Grok without adding a second filesystem scanner or provider-specific web/RPC paths.
Validation
pnpm exec vp checkpnpm exec vp run typecheck$skillchip storage, and successful native skill execution through ACP$skillregression checkNote
Medium Risk
Spawns provider CLIs on skill menu open and on Grok prompts with skill tokens; failures surface as typed errors and can block sends when discovery is required, but scope is provider adapters and composer UX rather than auth or persistence.
Overview
Project-scoped provider skills are exposed end-to-end: drivers can implement optional
listSkills(cwd), the registry and WebSocket layer addserver.listProviderSkills, and the chat composer loads skills for the current worktree when the$skill menu opens (with keyed caching and snapshot fallback only when discovery is unsupported).Codex lists skills via a scoped app-server probe (
includeModels: false, auth-probe timeout). Grok discovers viagrok --cwd <cwd> inspect --json(schema mapping, 10s timeout, typed errors). On sendTurn, Grok rewrites enabled$nametokens to/namefor ACP only when the prompt has non–env-var skill tokens;$PATH-style tokens skipinspect, and a committed model switch is kept if skill discovery fails afterward.The composer updates skill chip labels in place when metadata refreshes so an in-flight probe does not reset Lexical focus; submitted prompts can include a trailing
$skilltoken via sharedcollectComposerInlineTokensoptions.Reviewed by Cursor Bugbot for commit 1982e2f. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Expose provider skills in the chat composer via a new
server.listProviderSkillsRPC endpointserver.listProviderSkillsWebSocket RPC endpoint that queries provider-specific skills for a given instance and working directory, returning a structured error when unsupported.listSkillson Codex and Grok provider drivers; Grok uses a newlistGrokSkillsutility that runsgrok inspect --jsonwith a 10s timeout.$skilltokens to/skillin Grok prompts when the discovered skill is enabled; all-uppercase tokens are excluded from discovery to avoid treating env vars as skills.Macroscope summarized 1982e2f.