Installing the Skills

Installing the Skills

XrmGhost Skills follow the Agent Skills open standard. Installing one is simply a matter of putting the skill folder where your agent looks for skills — there is no package manager step and no marketplace. This page covers the location for each agent, the two scopes you can install into, and a common point of confusion worth getting out of the way first.

Agent Skills are not Claude Code plugins

This trips people up, so it is worth being explicit. Agent Skills (a SKILL.md file in a skills directory) and Claude Code plugins (a .claude-plugin/ package distributed through a marketplace) are two different ecosystems with two different install paths.

If you try to install these skills as if they were a plugin, it will not work:

• There is no claude skill install command — skill is not a Claude Code sub-command, and claude skill --help falls back to the main help, which can be misleading.
• claude plugin install <repo-url> will report “Plugin not found in any configured marketplace”, and claude plugin marketplace add <repo-url> fails because the repository has no .claude-plugin/marketplace.json — by design. It is a skills repository, not a plugin marketplace.

The correct path is the manual copy described below. It takes seconds once you know it.

Prerequisites

The skills assume the xg CLI is installed and set up. First-time setup — installing xg with winget install XrmGhost.Cli (the runtime host comes with it, in bin\; without winget, the signed xrmghost-cli-<version>-full.zip from GitHub Releases carries the same bundle), running xg init, and activating a license — is covered by Getting Started. If xg run reports that no Framework Host was found, run xg init (xg init --no-interactive in CI): the bundled host in bin\ is used first, then the managed install, then legacy locations. XrmGhost is distributed for evaluation; runs stop working as expected once the evaluation period lapses.

Where each agent looks for skills

Each agent loads skills from its own directory. You can install at project scope (only the current workspace sees the skill) or user scope (every project on your machine sees it).

Agent	Project-level (this workspace)	User-level (all projects)
Claude Code	.claude/skills/	~/.claude/skills/
GitHub Copilot CLI	.github/skills/	~/.copilot/skills/ or ~/.agents/skills/
Codex CLI	.agents/skills/	~/.agents/skills/
OpenCode	.claude/skills/ (Claude Code fallback)	~/.claude/skills/
Pi	.pi/skills/ or .agents/skills/	~/.pi/agent/skills/ or ~/.agents/skills/

Installing

Clone (or download) the xrmghost-skills repository, then copy the skill folder(s) you want into the right directory for your agent. Using Claude Code at user scope as the example:

git clone https://github.com/xrmghost/xrmghost-skills.git
mkdir -p ~/.claude/skills
cp -r xrmghost-skills/skills/debugging-dataverse-plugins-locally ~/.claude/skills/
cp -r xrmghost-skills/skills/authoring-dataverse-plugin-scenarios ~/.claude/skills/

Two rules matter when copying:

• Copy the whole skill folder, including any references/ subdirectory — supporting files are loaded relative to SKILL.md.
• Do not nest a skill one level too deep. The layout your agent expects is …/skills/<skill-name>/SKILL.md. A folder like …/skills/xrmghost-skills/debugging-.../SKILL.md will not be found.

For another agent, swap the destination for the matching row in the table above (for example ~/.copilot/skills/ for GitHub Copilot CLI, or .claude/skills/ for project scope).

Verifying the install

Start (or restart) your agent and confirm it can see the skills — in Claude Code, the skills appear in the available-skills list, and the agent will engage them when a task matches their triggers (writing a scenario, running a plugin locally, interpreting an xg result). A quick check is to ask the agent to run a plugin scenario locally and watch whether it reaches for xg run with the right flags.

The agent marker in xg telemetry

The debugging-dataverse-plugins-locally skill tells the agent to mark every xg invocation as agent-driven, so that the CLI’s telemetry records actor=agent and which agent is running (see Actor fields in xg privacy). The marker adds no command arguments; the agent prefixes each xg command with two environment variables, in the same shell command that invokes xg:

XRMGHOST_ACTOR="${XRMGHOST_ACTOR:-agent}" XRMGHOST_AGENT_NAME=<name> xg run ...

if (-not $env:XRMGHOST_ACTOR) { $env:XRMGHOST_ACTOR = 'agent' }; $env:XRMGHOST_AGENT_NAME = '<name>'; xg run ...

• <name> is the agent’s own identifier from the closed list claude-code, codex, copilot-cli, opencode, pi, gemini-cli, cursor, cline, mcp, other. An agent that is not certain which one it is omits XRMGHOST_AGENT_NAME and lets the CLI fall back to its own detection.
• An existing XRMGHOST_ACTOR is kept. If the variable is already set in the environment, the skill leaves it as it is, does not set XRMGHOST_AGENT_NAME either, and runs xg without the prefix.

The marker identifies the execution context only; it does not change how any xg command behaves.

Opting out of the marker

Because the skill keeps an existing value, set XRMGHOST_ACTOR=human in the environment the agent is launched from, before the session starts, so that every shell the agent opens inherits it:

# Linux / macOS
export XRMGHOST_ACTOR=human

# Windows (PowerShell)
$env:XRMGHOST_ACTOR = "human"

This opts out of the agent marker only: it also overrides the CLI’s automatic agent detection, and telemetry records still carry actor=human and is_ci. It is not a telemetry opt-out. To stop CLI telemetry, set XRMGHOST_TELEMETRY=0 instead, as described in xg privacy.

Keeping current

The per-agent location matrix and copy procedure are maintained in the repository README.md, which is the always-current source if a new agent is added or a path changes. A guided multi-agent installer — auto-detecting installed agents and letting you choose project vs user scope — is planned.