feat: wire up remote globalSkills with enterprise UI and architectural fixes [ENG-1774] (#10283)
- feat: wire up globalSkills consumption from remote config
The remote config schema already includes globalSkills (merged in #10236). The dashboard can save skills to remote config. This PR wires up the extension to read and use them.
Changes
State storage (Layer 1)
- Add remoteGlobalSkills to REMOTE_CONFIG_EXTRA_FIELDS
- Add remoteSkillsToggles to GLOBAL_STATE_FIELDS
Remote config transform/apply/clear (Layer 2)
- Map globalSkills → remoteGlobalSkills in transformRemoteConfigToStateShape
- Sync remoteSkillsToggles in applyRemoteConfig using frontmatter.name as the identity key (not entry.name)
- Clear remoteSkillsToggles in clearRemoteConfig
Skill discovery (Layer 3)
- discoverSkills accepts optional remoteSkillEntries parameter (pure utility, no StateManager coupling)
- getSkillContent accepts optional remoteSkillEntries parameter for remote content loading without disk I/O
- Precedence: remote (enterprise) > disk-global (user) > project
refreshSkills (Layer 3b)
- Reads remote entries from controller.stateManager, parses frontmatter, builds SkillInfo entries with alwaysEnabled field
UseSkillToolHandler (Layer 4)
- Toggle filter checks remoteSkillsToggles for remote: prefixed skills
- Directory note omitted for remote skills
- Passes remoteSkillEntries to both discoverSkills and getSkillContent
toggleSkill
- Routes remote: prefixed paths to remoteSkillsToggles keyed by name
Proto + webview
- Added always_enabled field to SkillInfo proto message
- Modal passes isRemote + alwaysEnabled to RuleRow for remote skills
- Uses skill.name as display label for remote skills
Design decisions
- frontmatter.name is the sole identity for remote skills (entry.name is ignored). This matches how local skills work.
- remote: path prefix distinguishes remote from disk skills in toggle stores and content loading.
- skills.ts remains a pure utility module with zero StateManager coupling. Callers inject remote entries as parameters.
- 42 unit tests covering discovery, precedence, content loading, toggle sync, and frontmatter parsing.
- fix: enforce alwaysEnabled in toggle sync to prevent stale false overrides
When applyRemoteConfig syncs skill toggles, synchronizeRemoteRuleToggles preserves existing toggle values — including false. If an admin later sets alwaysEnabled: true on a skill that a user had previously disabled, the stale false toggle would survive the sync. The UI would show the skill as locked-on (via the alwaysEnabled check in refreshSkills), but UseSkillToolHandler’s filter would see false in the toggle store and exclude it, causing a ‘Skill not found’ error for a skill the user can see is active.
Fix: after synchronizeRemoteRuleToggles, force any alwaysEnabled entry with a false toggle back to true. This makes the toggle store the single source of truth — both UI and handler now agree.
Adds 4 tests covering the alwaysEnabled enforcement edge cases.
- fix: deduplicate remote skill parsing, add drift validation, and fix architectural gaps
Extract shared parseRemoteSkillEntries utility (skills.ts)
- Single validation point for remote skill entries, replacing duplicated frontmatter parsing in skills.ts, refreshSkills.ts, and remote-config/utils.ts
- Enforces entry.name === frontmatter.name to catch drift between the dashboard and SKILL.md content (rejects with warning on mismatch)
Eliminate redundant frontmatter re-parsing in getSkillContent
- Was re-parsing every entry’s frontmatter to find a match by name
- Now uses entry.name for lookup since drift validation guarantees equality
Enforce alwaysEnabled in UseSkillToolHandler
- The toggle filter was missing the alwaysEnabled check, so a stale false toggle could hide an admin-locked skill from the model
- Now matches the logic in refreshSkills.ts
Add remote_skills_toggles to SkillsToggles proto
- toggleSkill now returns remoteSkillsToggles in the response, matching how remote rules/workflows already work
Separate Enterprise Skills section in UI
- Remote skills now render under their own “Enterprise Skills” header, consistent with how rules and workflows display remote entries
Update tests for new validation behavior
- Tests now use entry.name matching frontmatter.name (was deliberately mismatched before); added drift rejection tests
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix: enable viewing remote skills and fix tooltip text in RuleRow
- openRemoteFile now handles remote://skill/{name} URIs (was only rule and workflow), looking up content from remoteGlobalSkills
- RuleRow’s handleEditClick builds the correct URI type for skills (was falling through to “rule”)
- Tooltip text now uses ruleType (“View skill file”) instead of hardcoded “View rule file” for all remote entries
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix: soften drift validation to warn-not-reject, fix content lookup fallback
The strict entry.name !== frontmatter.name rejection was silently hiding org-configured skills when the dashboard’s entry.name didn’t match the SKILL.md frontmatter name.
- parseRemoteSkillEntries now warns on drift but uses frontmatter.name as the canonical identity instead of rejecting the entry
- getSkillContent falls back to frontmatter match when entry.name lookup misses (handles drift for content loading)
- openRemoteFile falls back to frontmatter match for skill view (same reason)
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix: include remote skills in system prompt and fix remote config race
The system prompt generation called discoverSkills() without passing remoteSkillEntries, so the model never learned about remote skills and never invoked use_skill for them. This was the actual cause of remote skills being invisible to the model despite showing in the UI.
Also fixes a race condition in applyRemoteConfig where clearRemoteConfig() wiped the in-memory cache before repopulating it field-by-field. Any concurrent reader (e.g., UseSkillToolHandler) during that window would see an empty cache. Replaced with atomic replaceRemoteConfig() that builds the new cache and swaps it in a single assignment.
- task/index.ts: pass remoteSkillEntries to discoverSkills, add remoteSkillsToggles + alwaysEnabled filtering (matching handler)
- StateManager: add replaceRemoteConfig() for atomic cache swap
- remote-config/utils.ts: use replaceRemoteConfig instead of clearRemoteConfig + setRemoteConfigField loop
- Remove debug logging from parseRemoteSkillEntries and handler
Co-Authored-By: Claude Opus 4.6 (1M context) noreply@anthropic.com
- fix: include remote skills in subagent path
Co-authored-by: Claude Opus 4.6 (1M context) noreply@anthropic.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802032778号
Cline
Meet Cline, an AI assistant that can use your CLI aNd Editor.
Thanks to Claude Sonnet’s agentic coding capabilities, Cline can handle complex software development tasks step-by-step. With tools that let him create & edit files, explore large projects, use the browser, and execute terminal commands (after you grant permission), he can assist you in ways that go beyond code completion or tech support. Cline can even use the Model Context Protocol (MCP) to create new tools and extend his own capabilities. While autonomous AI scripts traditionally run in sandboxed environments, this extension provides a human-in-the-loop GUI to approve every file change and terminal command, providing a safe and accessible way to explore the potential of agentic AI.
open -a "Google Chrome" index.html, which you run with a click of a button.Use any API and Model
Cline supports API providers like OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras and Groq. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you’re using OpenRouter, the extension fetches their latest model list, allowing you to use the newest models as soon as they’re available.
The extension also keeps track of total tokens and API usage cost for the entire task loop and individual requests, keeping you informed of spend every step of the way.
Run Commands in Terminal
Thanks to the new shell integration updates in VSCode v1.93, Cline can execute commands directly in your terminal and receive the output. This allows him to perform a wide range of tasks, from installing packages and running build scripts to deploying applications, managing databases, and executing tests, all while adapting to your dev environment & toolchain to get the job done right.
For long running processes like dev servers, use the “Proceed While Running” button to let Cline continue in the task while the command runs in the background. As Cline works he’ll be notified of any new terminal output along the way, letting him react to issues that may come up, such as compile-time errors when editing files.
Create and Edit Files
Cline can create and edit files directly in your editor, presenting you a diff view of the changes. You can edit or revert Cline’s changes directly in the diff view editor, or provide feedback in chat until you’re satisfied with the result. Cline also monitors linter/compiler errors (missing imports, syntax errors, etc.) so he can fix issues that come up along the way on his own.
All changes made by Cline are recorded in your file’s Timeline, providing an easy way to track and revert modifications if needed.
Use the Browser
With Claude Sonnet’s new Computer Use capability, Cline can launch a browser, click elements, type text, and scroll, capturing screenshots and console logs at each step. This allows for interactive debugging, end-to-end testing, and even general web use! This gives him autonomy to fixing visual bugs and runtime issues without you needing to handhold and copy-pasting error logs yourself.
Try asking Cline to “test the app”, and watch as he runs a command like
npm run dev, launches your locally running dev server in a browser, and performs a series of tests to confirm that everything works. See a demo here.“add a tool that…”
Thanks to the Model Context Protocol, Cline can extend his capabilities through custom tools. While you can use community-made servers, Cline can instead create and install tools tailored to your specific workflow. Just ask Cline to “add a tool” and he will handle everything, from creating a new MCP server to installing it into the extension. These custom tools then become part of Cline’s toolkit, ready to use in future tasks.
Add Context
@url: Paste in a URL for the extension to fetch and convert to markdown, useful when you want to give Cline the latest docs@problems: Add workspace errors and warnings (‘Problems’ panel) for Cline to fix@file: Adds a file’s contents so you don’t have to waste API requests approving read file (+ type to search files)@folder: Adds folder’s files all at once to speed up your workflow even moreCheckpoints: Compare and Restore
As Cline works through a task, the extension takes a snapshot of your workspace at each step. You can use the ‘Compare’ button to see a diff between the snapshot and your current workspace, and the ‘Restore’ button to roll back to that point.
For example, when working with a local web server, you can use ‘Restore Workspace Only’ to quickly test different versions of your app, then use ‘Restore Task and Workspace’ when you find the version you want to continue building from. This lets you safely explore different approaches without losing progress.
Contributing
To contribute to the project, start with our Contributing Guide to learn the basics. You can also join our Discord to chat with other contributors in the
#contributorschannel. If you’re looking for full-time work, check out our open positions on our careers page!Enterprise
Get the same Cline experience with enterprise-grade controls: SSO (SAML/OIDC), global policies and configuration, observability with audit trails, private networking (VPC/private link), and self-hosted or on-prem deployments, and enterprise support. Learn more at our enterprise page or talk to us.
License
Apache 2.0 © 2026 Cline Bot Inc.