Setup

Purpose

Guide the user through Claude Code's native configuration flow and report whether the remote Dometrain MCP server is reachable, without reading, printing, or writing the sensitive dometrain_api_key. Claude Code prompts for the required key when the plugin is enabled and owns its secure credential storage.

Check-only per the uniform setup contract's userConfig-only carve-out: this plugin's entire configuration surface is the native sensitive userConfig key, so check (default and only action) verifies and reports, and reconfiguration routes through Claude Code's native flow.

Mechanism note (why this skill does not read /mcp): /mcp is a human-run interactive command. No tool exposes its output to a model turn. The one real, model-visible signal for a failed remote server is Claude Code's own ToolSearch-surfaced connection error: "When a configured server fails to connect, Claude Code tells Claude which server failed and its connection error, including in ToolSearch results that find no matching tool... Requires tool search, which is enabled by default. In configurations without tool search... Claude Code doesn't report failed server connections to Claude." (https://code.claude.com/docs/en/mcp). This skill is built around that constraint, not around reading /mcp connection status directly.

Official contracts:

• https://code.claude.com/docs/en/plugins-reference#user-configuration
• https://code.claude.com/docs/en/plugins-reference#default-enablement
• https://code.claude.com/docs/en/mcp

Task

1. Check whether the dometrain plugin is enabled and whether its scoped MCP tools (e.g. list_courses, search_dometrain) are present in the current tool inventory. Do not inspect settings files, environment variables, process arguments, debug logs, credential stores, or the key itself.
2. When the plugin is disabled (no dometrain-scoped tool was ever attempted), direct the user to enable it through the /plugin interface or claude plugin enable dometrain. Claude Code's native prompt collects the required key. Do not run either command for the user and do not hand-edit pluginConfigs. For a non-interactive install (CI, a fleet bootstrap, a scripted machine setup), point to the headless path below instead.
3. When the plugin is enabled and a dometrain-scoped tool resolves (via direct tool-list presence or a successful ToolSearch match), report connected: the server started and the key was supplied. Do not claim the key has valid API access beyond that. A connection-layer 401/403/429 rejection (per Dometrain's own README Troubleshooting section) would prevent the tool from resolving at all, so resolution itself is the strongest signal this skill can observe.
4. When the plugin is enabled but no dometrain-scoped tool resolves, report failed or unverified:
   • If ToolSearch returned a connection error for the dometrain server, quote it verbatim.
   • Otherwise do not assert why. Claude Code does not report failed connections to Claude in a configuration without tool search, and this skill cannot inspect the environment to tell whether tool search is active. Direct the user to run /mcp themselves rather than claim knowledge it does not have.
   • After the user reconfigures the key, require /reload-plugins or a new session before rechecking tool availability.

Headless installation

For a non-interactive install such as CI, a fleet bootstrap, or a scripted machine setup, seed the key on the initial install instead of the interactive /plugin prompt. Three steps, all required:

claude plugin marketplace add <source> --scope <scope>
claude plugin install dometrain@<marketplace> -s <scope> --config dometrain_api_key=<your-key>
claude plugin enable dometrain -s <scope>

Both placeholders are bootstrap inputs, not lookups: before the first install there is no record to read them from. <marketplace> is the name the catalog registers under when it is added, and <scope> is the scope the bootstrap chooses: user, project, or local. marketplace add and install default to user when the flag is omitted, while enable auto-detects. Carry the same <scope> through all three. Note the asymmetry: marketplace add spells it --scope only, while install and enable also accept the -s short form. Registering at user while installing at project leaves the marketplace declaration out of the project's checked-in settings, so a fresh clone or CI agent carries the enabled plugin with no registered marketplace to resolve it from.

The enable step is not optional. This plugin ships defaultEnabled: false, so it installs DISABLED. The install seeds the key but leaves the MCP server, and therefore every dometrain tool, unavailable until it is enabled (Default enablement, which also notes claude plugin enable auto-detects the scope when -s is omitted; passing it explicitly keeps the sequence deterministic in CI). A bootstrap that stops after install looks successful and delivers no tools.

Rotating or clearing the key: /plugin configure dometrain@<marketplace> (interactive, any time) is the recommended rotation path regardless. It masks input, where a key passed on the command line lands in shell history and the process table.

Headless --config reruns follow the plugin-reconfiguration convention, which owns the verified-version record (https://github.com/melodic-software/claude-code-plugins/blob/main/docs/conventions/plugin-reconfiguration/README.md): against an already-installed plugin a plain claude plugin install … --config prints already installed and still writes the value, but that record covers only a non-sensitive option, and whether it holds for a sensitive option such as dometrain_api_key has not been verified, so do not rely on it for a credential. Do not uninstall to rotate either: uninstalling drops this plugin's entire stored pluginConfigs entry, resetting every option in the README's Options reference to its manifest default, and it can drop the enabledPlugins entry as well. A defaultEnabled: false plugin reinstalls DISABLED, so a rotation that ends at install completes with no tools available.

Full detail, including the command-line-exposure caveat, is in the README's Rotating or clearing the key section.

Output

Report exactly one state: disabled, connected, or failed or unverified. Include the exact next action when the state is not connected.

Sensitive values use the macOS Keychain, or ~/.claude/.credentials.json on platforms where no supported keychain is available. Never read or reveal either location's contents.

Namespace-collision note

Dometrain ships its own official Claude Code plugin (github.com/Dometrain/mcp) whose plugin.json name is also "dometrain". If the user has that plugin enabled too, do not attempt to detect the collision by comparing MCP tool-name prefixes. A true collision produces an identical, not divergent, prefix, so no prefix comparison can distinguish "one plugin enabled" from "two colliding plugins enabled." Point the user to this plugin's README collision warning instead.

Boundaries

• Do not read, echo, log, copy, or persist the API key.
• Do not write the plugin cache, Claude Code user settings, or pluginConfigs, per the uniform setup contract (docs/PLUGIN-PHILOSOPHY.md "Setup is explicit and repeatable" in the marketplace repository).
• Do not call a Dometrain tool during setup. Resolution via tool inventory / ToolSearch is sufficient and spends no quota.
• Do not claim to have read /mcp connection status. No tool exposes it to a model turn.