Power Platform on the CLI, Part 1: What Copilot CLI Is and How Plugins Are Structured

Microsoft now ships an official set of agent plugins for Power Platform development — the microsoft/power-platform-skills marketplace. It works with two agentic command-line tools that happen to share the same plugin format: GitHub Copilot CLI and Anthropic's Claude Code.

This series walks through the whole thing end to end: what these CLIs are, how to pull down every Power Platform plugin, how to read a plugin to understand what it does, a tour of all seven plugins, and finally one worked example that stitches them all into a single solution.

Because the two CLIs are so similar, I'll show the Copilot CLI and Claude Code commands side by side the whole way through. Pick whichever you have — the plugins are identical.

What is an "agentic CLI"?

If you've used GitHub Copilot inside VS Code, you know the autocomplete-and-chat experience. An agentic CLI is a different animal. It's a program you run in your terminal that can hold a conversation, read and write files in your project, run shell commands, call MCP servers, and take multi-step actions on your behalf — pausing to ask permission along the way.

Two mainstream ones exist today, and they matter here because they read the same plugin format:

• GitHub Copilot CLI — GitHub's terminal agent, launched from the copilot command. Backed by your GitHub Copilot subscription.
• Claude Code — Anthropic's terminal agent, launched from the claude command. Backed by a Claude subscription or API key.

The reason a single Microsoft marketplace can serve both is that they converged on a shared idea of a "plugin": a folder containing skills, agents, MCP server definitions, and a manifest. Copilot CLI looks for a .plugin/ folder; Claude Code looks for a .claude-plugin/ folder; the Power Platform repo simply ships both, with identical contents.

Installing the CLI

Both install through npm and both want a reasonably recent Node.

GitHub Copilot CLI (needs Node.js 22+ and an active Copilot subscription):

npm install -g @github/copilot
copilot          # first launch prompts you to authenticate

Inside the session, authenticate with the /login slash command and follow the prompts. If you'd rather use a token, create a fine-grained personal access token with the Copilot Requests permission and export it as COPILOT_GITHUB_TOKEN (or GH_TOKEN / GITHUB_TOKEN).

Claude Code (needs Node.js 18+ and a Claude account):

npm install -g @anthropic-ai/claude-code
claude           # first launch walks you through sign-in

Both are interactive REPLs. You type a request in natural language, the agent proposes actions, and you approve them. Slash commands (anything starting with /) control the tool itself rather than talking to the model — that's how you'll manage plugins.

Where does everything live on disk?

This is the part that trips people up, so it's worth being concrete. Neither tool dumps plugins into your project. They keep a per-user home directory.

Copilot CLI organizes it like this:

~/.copilot/
├── installed-plugins/
│   ├── <marketplace-name>/
│   │   └── <plugin-name>/        # a plugin installed from a marketplace
│   └── _direct/
│       └── <source-id>/          # a plugin installed directly, not via a marketplace
└── ...                           # config, logs, session state

Marketplaces themselves are cached separately in an OS-specific spot — ~/.cache/copilot/marketplaces/ on Linux, ~/Library/Caches/copilot/marketplaces/ on macOS, the equivalent on Windows. Each plugin also gets a private writable scratch directory exposed to it as the COPILOT_PLUGIN_DATA environment variable.

Claude Code keeps a parallel structure under its own home:

~/.claude/
├── plugins/                      # installed plugins + marketplace clones
├── settings.json                 # permissions, default mode, etc.
└── ...

The mental model is the same in both: a marketplace is a git repo full of plugins, and installing a plugin copies (or links) that plugin's folder into your CLI's home directory so its skills and agents become available in every session.

Anatomy of a plugin folder

Here's where it gets useful. Once you know the shape of a plugin, you can open any of them and figure out what it does in about a minute — no documentation required. Every plugin in the Power Platform marketplace follows the same layout. Here's the real power-pages plugin, trimmed:

power-pages/
├── .plugin/plugin.json           # manifest (Copilot CLI reads this)
├── .claude-plugin/plugin.json    # identical manifest (Claude Code reads this)
├── .mcp.json                     # MCP servers this plugin brings along
├── AGENTS.md                     # instructions the agent loads for this domain
├── CLAUDE.md -> AGENTS.md        # symlink so both tools read the same guidance
├── README.md
├── skills/                       # the capabilities you can invoke
│   ├── create-site/
│   │   └── SKILL.md
│   ├── deploy-site/
│   ├── plan-alm/
│   └── ...
├── agents/                       # specialized sub-agents the skills delegate to
│   ├── data-model-architect.md
│   └── ...
├── references/                   # reference docs the skills pull in as needed
├── scripts/                      # helper scripts (version checks, launchers)
└── hooks/                        # lifecycle hooks

A few of these folders carry most of the meaning:

The manifest (plugin.json) is the plugin's identity card — name, version, description, author, and a list of keywords. Copilot CLI checks for it in .plugin/plugin.json, then plugin.json, then .github/plugin/plugin.json, then .claude-plugin/plugin.json, in that order. Claude Code looks in .claude-plugin/plugin.json. Ship both and you're portable.

Skills (skills/*/SKILL.md) are the actual capabilities. Each skill is a folder with a SKILL.md file whose front matter declares its name, a description of when to use it, whether a human can invoke it directly, and which tools it's allowed to touch. When you ask the CLI to "create a Power Pages site," it's a skill named create-site that gets loaded to guide the work. We'll read one line by line in Part 2.

Agents (agents/*.md) are narrower specialists a skill can hand work to — for example a data-model-architect that focuses purely on designing Dataverse tables. This is how the plugins parallelize and stay focused.

MCP config (.mcp.json) lists Model Context Protocol servers the plugin depends on. Power Pages, for instance, ships a Playwright server (so the agent can open your site in a browser and check its work) plus the hosted Microsoft Learn MCP (so it can look up authoritative docs instead of guessing). The CLI launches these on demand — you don't install them separately.

AGENTS.md / CLAUDE.md is the always-on briefing for that domain: conventions, guardrails, and how the skills fit together. The symlink means Copilot CLI (AGENTS.md) and Claude Code (CLAUDE.md) read the exact same guidance.

Why this structure is worth understanding

You don't have to trust a plugin blindly. Because everything is plain files — JSON manifests, Markdown skills, a small MCP config — you can read exactly what a plugin will do and what it's allowed to touch before you run it. That transparency is the whole point of the next post, where we'll add the Power Platform marketplace, install the plugins, and then open them up to see what each one actually does.

---

Next up — Part 2: adding the power-platform-skills marketplace, installing the plugins, and reading a plugin's plugin.json and SKILL.md to see exactly what it does.

Sources: GitHub Copilot CLI docs · microsoft/power-platform-skills``