Sync Host Views

Sync Host Views Skill

The VS Code extension owns all webview "views" (a.k.a. screens). The Visual Studio extension and the JetBrains plugin are thin hosts that load a subset of the same compiled webview bundles inside a WebView2 / JCEF browser.

Neither host commits webview content to git any more (see docs/adr/VS-WEBVIEW-BUNDLE-SOURCING.md): both copy the bundles fresh from vscode-extension/dist/webview at build time — Visual Studio via the .csproj's CopyWebviewBundles MSBuild target, JetBrains via prepareBundledAssets in build.gradle.kts. So there is nothing left for this skill to refresh or flag as stale; it only tracks view-LIST drift — which named bundles each host's build config references — the same way for both hosts:

• 🛑 Never silently add a new VS Code view to a host. New views are detected and handed to the user to decide.
• 🔎 Flag views a host references that VS Code no longer builds (orphans).

One view == one screen

Each entry in the VS Code esbuild entryPoints map is exactly one webview bundle and one user-facing screen. "Add a screen" therefore means "add a bundle to the host include list and wire up navigation to it" — that is the human decision this skill protects.

The three sources of truth

Run the script (see below) for the current per-host view counts and coverage — this drifts every time a view is added or a host picks one up. Views a host doesn't ship are intentionally excluded, not missing.

Why nothing is committed for either host

Neither host commits webview bundle content to git. Both copy the compiled bundles fresh from vscode-extension/dist/webview at their own build time:

• Visual Studio does it via the CopyWebviewBundles MSBuild target in AIEngineeringFluency.csproj (BeforeTargets="Build"), and the CI/local build scripts (visualstudio-build.yml, visualstudio-publish.yml, release.yml, build.ps1) additionally do a wholesale directory copy before MSBuild runs.
• JetBrains does it via prepareBundledAssets in build.gradle.kts.

This used to differ — Visual Studio committed its copies to the repo as a "possibly stale" fallback, which drifted out of sync in practice (see docs/adr/VS-WEBVIEW-BUNDLE-SOURCING.md). That fallback has been removed: both hosts now work exactly like JetBrains always did, so there is nothing left for this skill to refresh or check for staleness — only the two hosts' include lists (which named views each ships) can still drift from the canonical VS Code set, and that's all this script tracks.

What the script reports

sync-host-views.js classifies, per host, every canonical view as:

1. tracked — the host's build config lists this view.
2. NEW — VS Code builds it but the host does not list it. Requires a human decision; the script exits 3.
3. ORPHAN — the host lists a view VS Code no longer builds. Mechanical drift; the script exits 1.

Usage

# Detect drift and new screens (read-only). Run from the repo root.
node .github/skills/sync-host-views/sync-host-views.js

# Machine-readable output (CI / further processing).
node .github/skills/sync-host-views/sync-host-views.js --json

# Help.
node .github/skills/sync-host-views/sync-host-views.js --help

Build the bundles first if dist/webview is empty (only affects the informational dist/webview built line in the report — list-drift detection works either way):

cd vscode-extension && npm run package

Exit codes