claudeSessionCustomizationDiscovery.ts ×4

Frontier kind: Code frontier

unlabeled · c_fc1af903faa7

23 tests · 19640 LOC · 70 files · introduces 0 tests · 48 LOC · 1 file

Introduces — evidence that enters the hierarchy at this concept

Code
4 ranges48 lines · 1 files
Tests
0 tests

Contains — complete concept membership

All code (extent)
2063 ranges19640 lines · 70 files · Browse complete extent
All tests (intent)
23 testsBrowse complete intent

Neighbourhood graph

The orange circle is the focus. Violet and green circles are every ancestor and descendant, broader and narrower, at any distance; blue squares and pink diamonds are the introduced files and exact introduced tests of every visible concept, not only the focus's. Arrows point from broader to narrower concepts and bridge only concepts omitted from this view. Undirected links show source or test introduction. Concept and file size follows LOC; exact test nodes use test-count units.

Introduced files, introduced tests, and structurally relevant concept specialization

In the embedded map, ordinary wheel input scrolls the page; use the visible controls to zoom and drag to pan. Open the full-screen map for canvas navigation: wheel pans, Ctrl/Command plus wheel zooms, and arrow keys pan when this region is focused. On touch screens, open the full-screen map to pan or pinch. If JavaScript or WebGL is unavailable, use the native relationship evidence on this page.

Graph controls are ready.

Interactive rendering requires JavaScript and WebGL. Use the native relationship evidence on this page while the interactive map is unavailable.

Native relationship evidence

Every exact file and test below is linked only from the concept that introduces it.

Introduced tests

Every collected test enters the hierarchy at exactly one concept.

No tests are introduced at this concept. Its intent tests are introduced by other concepts.

Introduced code

Every collected source range enters the hierarchy at exactly one concept.

1 file ranked by introduced lines: 48 introduced LOC across 4 ranges. Expand a file to inspect source; the > gutter marks introduced lines.

src/vs/platform/agentHost/node/claude/customizations/claudeSessionCustomizationDiscovery.ts 48 introduced LOC · 4 ranges

Open complete file

274 */
275 export function buildDiscoveredCustomizations(
276 > discovered: readonly (IParsedAgent | IParsedSkill | IParsedRule)[], claudeSessionCustomizationDiscovery.ts
277 > mcpServers: readonly McpServerCustomization[],
278 > hooks: readonly HookCustomization[],
279 > nativePlugins: readonly IResolvedNativePlugin[],
280 > workingDirectory: URI | undefined,
281 > userHome: URI,
282 > sdk: ISdkResolvedCustomizations | undefined,
283 > ): readonly Customization[] {
284 > // Native plugins the live session actually loaded → surfaced as top-level
285 > // containers (passed to the mapper at the end). The SDK `init.plugins`
286 > // reports each loaded plugin's `source` (its `<plugin>@<marketplace>` id)
287 > // and a `path`. Match on `source` against the resolved plugin id first — it
288 > // is exact and stable — and fall back to a normalized `path` match (older
289 > // SDKs without `source`). The `path` alone is unreliable: for a
290 > // workspace-`local`-scoped plugin the SDK can report a non-cache path that
291 > // never matches the resolved root. The plugin is the atomic filtering unit.
292 > //
293 > // A plugin's bundled components are ALSO reported by the live SDK as
294 > // agents / commands / MCP servers. Collect each surfaced plugin's own
295 > // parsed component names so those SDK entries are suppressed from the
296 > // standalone fallbacks below — each component then appears once, under its
297 > // plugin container, not also loose in the per-scope lists (Decision PB-10).
298 > // The SDK names plugin components inconsistently (agents namespaced as
299 > // `<plugin>:<name>`, skills usually bare), so both forms are registered.
300 > // Only *surfaced* plugins contribute, so a loaded-but-unsurfaced plugin's
301 > // components are never silently dropped. A single pass matches each native
302 > // plugin to its SDK entry, building the visible set and the suppression
303 > // name sets together (no second `find`).
304 > const visiblePlugins: IResolvedNativePlugin[] = [];
305 > const pluginAgentNames = new Set<string>();
306 > const pluginSkillNames = new Set<string>();
307 > const pluginMcpNames = new Set<string>();
308 > if (sdk) {
309 for (const p of nativePlugins) {
310 const sdkPlugin = sdk.plugins.find(s => s.source === p.id || URI.file(s.path).fsPath === p.root.fsPath);
319 for (const m of p.parsed.mcpServers) { add(pluginMcpNames, m.name); }
320 }
322 visiblePlugins.push(...nativePlugins);
323 }
325 > // The read-only "Built-in" skills container: pre-materialize the curated
326 > // list, post-materialize the live SDK command set minus the disk skills
327 > // (and minus plugin-contributed skills, which belong to a plugin container).
328 > // Appended to whichever projection is returned below so the SDK-vs-curated
329 > // decision for built-in skills sits next to the one for built-in agents.
330 > const diskSkillNames = new Set(
331 > discovered.filter(d => d.customization.type === CustomizationType.Skill).map(d => d.name)
332 > );
333 > const builtinSkills = sdk
334 ? buildSdkBuiltinSkillsContainer(sdk.commands.filter(c => !pluginSkillNames.has(c.name)), diskSkillNames)
335 : buildClaudeBuiltinSkillsContainer(diskSkillNames);
336 > const withBuiltinSkills = (list: readonly Customization[]): readonly Customization[] => claudeSessionCustomizationDiscovery.ts
337 > builtinSkills ? [...list, builtinSkills] : list;
338 >
339 > if (!sdk) {
340 // Pre-materialize there is no live agent set, so seed the curated
341 // built-in agents alongside the disk agents. They use the same