Setup Dependencies

Most of this plugin needs nothing beyond Node. Roughly three quarters of its skills run with no external tools at all. This skill handles the rest: document converters that need Pandoc, a few visual skills that use optional render helpers, and two MCP servers that back charts and browser verification.

Nothing here installs without consent. A dependency check is read-only.

Unified Source Setup

The source checkout provides one root helper. Without switches it connects Alex Mall if missing, refreshes only its catalog and reports plugin/dependency versions without installation or activation. Marketplace registration and caches can change; this is not a wholly read-only host operation. The standalone checker below remains read-only.

With -Apply, the helper installs/updates the latest Mall plugin, bootstraps its owned instructions with conflict checks, then uses that installed package's dependency registry and launcher. It installs exact reviewed npm pins and only missing Windows Pandoc (winget) and selected-Python Pillow (configured pip). Existing system tools are checked, not silently upgraded. Python installation, forced elevation, agreement acceptance and policy bypasses are excluded. Missing prerequisites stop dependency installation with setup guidance. -VerifyOnly adds strict no-install readiness checks but still refreshes that selected catalog. Unrelated Agency marketplaces, plugins, credentials and MCP registrations are not refreshed or changed by the helper. This source flow is separate from the MCP-only provisioner below and from the helpers preserved inside older immutable release payloads. The checker itself has no install mode.

Check First

node <this-skill>/scripts/check-dependencies.cjs

The report covers three things: external tools, the MCP servers, and the optional plugins that extend this package. It writes nothing.

Add --json for a machine-readable version.

For MCP packages, the report distinguishes directory presence (installed), exact metadata and library checks (versionMatched), and a bounded successful --version launch probe (launchable). Empty package directories are not ready. present/allPresent require the version and launch checks, not just a folder. Host connectivity is separate: hostConnected is null and connectionStatus is not-observed until the host is checked independently. These probes do not demonstrate API authentication or actual renderer output.

Checker, provisioner, and launcher share runtime selection. The default is ~/.copilot/plugin-data/alex-act-one/runtime; ALEX_ACT_ONE_RUNTIME_ROOT selects an alternate location. Checker/provisioner --runtime-root <path> takes precedence. Point the host launcher's environment at that same alternate runtime; choosing a provisioning path does not rewrite host configuration.

What Is Optional

Nothing outside Node is required to use this package. "Required" is always relative to a capability, so the report sorts every item into three tiers:

The two MCP servers are provisioned by one command but they are not equally important, and the report tiers them separately. Flint is the only one whose absence stops a skill outright: flint-chart and flint-theme call its tools throughout and have no fallback. Playwright has one, documented in render-verify's own description.

The distinction matters when reporting to a user. A missing Pandoc means the affected converters are unavailable and should be named. A missing jszip means one output is plainer. A missing add-on means nothing at all, and telling someone to install one to "fix" a problem is wrong.

Plugin installation is not handled here. install-visual-companions and setup-enterprise own those flows because they carry the marketplace registration, the consent gates, and the post-install caveats — several companions pull roughly 100 MB of Chromium each. This skill reports the state so one command shows the whole picture; it does not duplicate their install logic.

Before proposing browser setup, inspect the active host's native capabilities. Keep the pinned Playwright fallback for an actual missing or unverified case; neither install it silently nor remove it merely because a native browser exists.

Plugin counts depend on which store the host reads. copilot plugin list follows COPILOT_HOME when set and ~/.copilot otherwise, and different apps set different stores, so a plugin installed for one app may not appear for another. The report prints the store it read for that reason.

Install With Consent

Use the unified root helper after reviewing its status report and installation scopes. Only its explicit -Apply path changes plugin, instruction or dependency state. The checker rejects the retired --apply option before running probes; it cannot start a second unmanaged npm/pip installation path. For MCP-only setup, use the provisioner below.

MCP Servers

Two pinned servers, provisioned together but tiered differently. They install into plugin-private state and are launched by a direct Node shim, never by npm or npx.

Provisioning selects all MCP servers by default. Use --server flint to select only Flint and its independently exact-pinned library. The launcher checks both metadata versions before invoking Flint; other server pins remain unchanged.

Procedure:

1. Run node <this-skill>/scripts/provision-runtime.mjs with no flags. It prints the effective npm config get registry, the exact package set, and the mutation boundary. It changes nothing.
2. Show that preview and ask whether to apply it. Installing the plugin is not consent for a separate package-network operation.
3. On approval, rerun with --apply. Success requires exact installed metadata, the server-resolved Flint library where applicable, and a bounded launch probe for each selected server. npm exit zero alone is not readiness.
4. Reload the host so its MCP processes restart through the direct launcher, then verify the expected MCP tools/connectivity there. No host connection is claimed by the package installation or standalone version probe.

Metadata, plugin-inventory, and installation subprocesses have finite waits; timeout/startup failures remain explicit. A failed install or verification can leave partial package state and must not be reported as provisioned successfully.

If registry metadata advertises backend tarballs that npm policy cannot fetch directly, do not enable remote fetching or change the registry. The source helpers recognize only the configured https://packagefeedproxy.microsoft.io/npm/ endpoint and preview its confirmed Microsoft backend prefix automatically. With npm 12+ and normal installation consent, matching tarballs are routed through that registry for the install command only. No corporate-network inference, persistent npm edits, retries, or broader routing occur. --registry-tarball-prefix <HTTPS-prefix/> overrides detection with a separately confirmed explicit prefix. Other registries require that explicit selection. The root PowerShell helper uses the same detection and previews it; its -VerifyOnly mode applies no routing and fetches no packages. The immutable 0.9.5 package predates automatic detection.

The provisioner installs nothing globally and never passes --registry or edits .npmrc. Whatever registry the user has configured is the one it uses.

Registering The Servers With Microsoft Scout

Provisioning puts the servers on disk. Registering tells a host they exist. Copilot CLI and VS Code do the second step themselves by reading plugin.json → mcpServers. Scout does not. It keeps its own registry at ~/.scout/m-mcp-servers.json and ignores the plugin manifest, so on Scout every skill loads while every server it calls is missing. That reads as a broken package rather than an unregistered one, which is why this step is explicit.

node <this-skill>/scripts/register-scout-mcp.mjs

Previews by default: it prints the plugin root it resolved, the registry path, and one line per server. --apply writes, backing the existing registry up to a timestamped .bak-alex-act-one-* file first.

Two translation details this script exists to handle, both silent failures if done by hand:

• Scout wraps the launch spec in config and expects type: "command". The manifest's flat type: "stdio" is not the same shape.
• Scout resolves nothing relative to the plugin. Manifest args carry package-relative script paths and must be made absolute.

Scout must be fully restarted afterwards — not just given a new conversation. It handshakes servers at startup and populates each tools array from that handshake; an empty array is the correct on-disk state before the first launch.

The registration points at whichever plugin copy the script was run from. Run it from the installed package, not a working checkout, unless the intent is to test uncommitted changes.

Why alex-playwright and not playwright

Scout ships a built-in browser server already named playwright, so the package registers its own under alex-playwright. This is not cosmetic. Scout's built-in blocks the file: protocol, which is the case render-verify centres on — inspecting an HTML, SVG, or PNG artifact just written to disk. The package's server carries --allow-unrestricted-file-access and can open it. The distinct name lets both coexist: the host's for ordinary web pages, this one for local artifacts.

Checking For MCP Updates

Run provision-runtime.mjs --check-updates. It compares each exact pin against dist-tags.latest and changes nothing. If a stable update exists, stop: run compatibility checks, update the source pins and guidance together, and release them. Private runtime state must never run ahead of reviewed source.

Failure Handling

Anti-Patterns

Would Revise If

Revise if a supported host cannot launch the private runtime directly, if a direct launch starts npm or npx, or if the dependency report and the error messages skills emit ever disagree.

Compatibility command constraints: setup-dependencies

Default to read-only dependency reporting. Explain the missing capability and obtain consent before installing reviewed dependencies.