Estimated reading time: 19 minutes

Target audience: Power Platform developers, .NET developers, and TypeScript/React developers who want to start using GitHub Copilot CLI as their primary terminal-native AI coding agent.

What you’ll learn: How to install and configure Copilot CLI, how to work with its agentic modes, how to extend it with Agent Skills and MCP servers, and how to integrate it into your Power Platform ALM workflow — with practical examples at every step.

Prerequisites: A paid GitHub Copilot subscription (Pro, Pro+, Business, or Enterprise). Node.js 18+ installed. Basic familiarity with the command line.

Understanding GitHub Copilot CLI

GitHub Copilot CLI reached General Availability on February 25, 2026, graduating from its September 2025 public preview into a production-ready tool for all paid Copilot subscribers.

It is not a chatbot in a terminal. It is an autonomous coding agent — meaning it can plan multi-step tasks, edit files, run shell commands, delegate to specialized sub-agents in parallel, and remember your codebase across sessions, all without leaving the command line.

The key difference from the older gh copilot suggest command:

For Power Platform developers specifically, this matters because PAC CLI, solution export/import pipelines, and PCF control toolchains all live at the terminal. Having an agent that understands your Dataverse environment, reads your GitHub Actions workflows, and executes PAC CLI commands on your behalf changes what “developer productivity” means.

Installation and First Launch

Install via your preferred package manager

# npm (all platforms — most portable)
npm install -g @github/copilot

# macOS — Homebrew (auto-updates)
brew install github/tap/copilot

# Windows — WinGet (auto-updates)
winget install GitHub.Copilot

# Linux / CI — shell script (auto-updates)
curl -fsSL https://cli.github.com/packages/copilot/install.sh | sh

# npm (all platforms — most portable)
npm install -g @github/copilot

# macOS — Homebrew (auto-updates)
brew install github/tap/copilot

# Windows — WinGet (auto-updates)
winget install GitHub.Copilot

# Linux / CI — shell script (auto-updates)
curl -fsSL https://cli.github.com/packages/copilot/install.sh | sh

Auto-update note: Homebrew, WinGet, and the shell script installations auto-update. npm requires npm update -g @github/copilot to get new versions. Copilot CLI ships frequent updates — staying current matters.

Copilot CLI is also pre-installed in GitHub Codespaces and available as a Dev Container Feature if you use container-based development.

Authenticate and launch

# Launch Copilot CLI — this triggers browser-based GitHub authentication on first run
copilot

# Launch Copilot CLI — this triggers browser-based GitHub authentication on first run
copilot

On first launch, you will be asked to confirm you trust the files in the current directory. This is a security check — Copilot CLI has read/write/execute access to files in the folder you launched from.

Verify your installation

# Check version
copilot --version

# Check available models (confirms authentication worked)
/model

# View your current session context
/context

# Check version
copilot --version

# Check available models (confirms authentication worked)
/model

# View your current session context
/context

Core Concepts: How the Agent Works

Before diving into workflows, three concepts are worth internalizing.

Context window and auto-compaction

Copilot CLI maintains a rolling context window across your session. When it reaches approximately 95% capacity, it auto-compacts — summarizing older history while preserving the most relevant recent context. Sessions can run as long as your task requires, without you manually resetting anything.

Repository memory (cross-session)

As you work in a repository over time, Copilot CLI learns and stores facts about your codebase: naming conventions, frequently used patterns, your preferred solution names, environment URLs, team standards. This memory persists when you close the terminal and is loaded automatically the next time you open a session in the same repository. You can inspect it with /memory show.

Progressive tool trust

By default, Copilot CLI asks for approval before running shell commands and editing files. You can adjust trust levels per session or per project. The recommended approach is to pre-approve specific tools rather than granting blanket trust — this keeps you in control while reducing friction for known-safe operations like pac * or npm *.

Agentic Modes: Interactive, Plan, and Autopilot

Copilot CLI has three distinct operating modes. Choosing the right one for each task significantly affects quality and safety.

Interactive mode (default)

The default. You type a prompt, the agent responds with a plan or action, you approve or push back, it continues. Good for most day-to-day work.

copilot
> List all solutions in my dev environment and show their version numbers

copilot
> List all solutions in my dev environment and show their version numbers

Plan mode — Shift+Tab

Before writing a single line or running a single command, the agent produces a structured implementation plan for your review. You see every step before anything happens.

copilot
> [Press Shift+Tab to enter plan mode]
> Set up a new PCF control named CustomerTimeline for model-driven apps

copilot
> [Press Shift+Tab to enter plan mode]
> Set up a new PCF control named CustomerTimeline for model-driven apps

Copilot presents: “Here’s what I plan to do: 1. Run pac pcf init… 2. Install npm dependencies… 3. Build to verify… Approve?” You review and approve before execution begins. Use this for anything irreversible or complex.

Autopilot mode — Shift+Tab twice

Full autonomous execution. The agent plans, executes tools, iterates on errors, and reports back when done. No per-step approval.

copilot
> [Press Shift+Tab twice to enter autopilot mode]
> Write Jest integration tests for our LeadQualification Power Automate flow

copilot
> [Press Shift+Tab twice to enter autopilot mode]
> Write Jest integration tests for our LeadQualification Power Automate flow

Use autopilot for well-scoped, lower-risk tasks like writing tests, generating documentation, or refactoring a single file. Reserve it for tasks where the blast radius of a mistake is limited.

Background delegation — & prefix

Prefix any prompt with & to delegate the task to GitHub’s cloud coding agent, freeing your local terminal immediately.

> & Export the CustomerPortal solution and create a PR with the unpacked components

> & Export the CustomerPortal solution and create a PR with the unpacked components

Later, use /resume to pick up the session and review what was done.

Essential Commands Reference

These are the commands you’ll use most often. All slash commands are available in any active session.

Navigation and context

File management and review

Model and configuration

Plugins and skills

Agents and parallel work

Choosing Your AI Model

Use /model at any point in a session to switch models. Different models suit different task types.

Practical model strategy:

1. Start sessions with Haiku 4.5 for exploration — reading files, understanding the codebase, asking questions.
2. Switch to Sonnet 4.6 for generation tasks — writing code, creating workflows, refactoring.
3. Reach for Opus 4.6 when you need deeper reasoning — architecture review, complex debugging, designing multi-agent systems

copilot
> [explore the repo first with Haiku]
/model claude-haiku-4-5
> Summarize the solution structure in this repo and list all PAC CLI scripts

> [then switch to Sonnet for the real work]
/model claude-sonnet-4-6
> Now generate a GitHub Actions workflow for automated solution export based on what you found

copilot
> [explore the repo first with Haiku]
/model claude-haiku-4-5
> Summarize the solution structure in this repo and list all PAC CLI scripts

> [then switch to Sonnet for the real work]
/model claude-sonnet-4-6
> Now generate a GitHub Actions workflow for automated solution export based on what you found

Configuring Your Project

Two configuration files make every subsequent session in your repository smarter: AGENTS.md and .github/copilot/config.json.

AGENTS.md — project context loaded on every session start

This file tells the agent what kind of project it is working in, every time it starts. Generate a baseline with /init, then customize it.

# AGENTS.md

## Project Overview
Power Platform solution repository for CustomerPortal — a Dynamics 365 Customer Service
customization including model-driven apps, PCF controls, and Power Automate flows.

## Technology Stack
- Power Platform CLI (PAC CLI) for ALM operations
- TypeScript + React for PCF controls (Fluent UI v9 component library)
- GitHub Actions for CI/CD pipelines
- Dataverse as the data platform
- Node.js 20 for scripts and tests

## Environment Naming
- Development: DEV-CustomerPortal (https://devenv.crm.dynamics.com)
- Test: TEST-CustomerPortal (https://testenv.crm.dynamics.com)
- Production: PROD-CustomerPortal (https://prodenv.crm.dynamics.com)

## Branching Strategy
- `main` → triggers export from DEV and commits unpacked solution
- `release/*` → triggers import to TEST with Solution Checker gate
- Tags `v*` → triggers production import (manual approval required)

## Conventions
- Solution unique name: CustomerPortal
- PCF controls namespace: ELCA.CustomerPortal
- Always run `pac solution check` before importing to TEST or PROD
- Use `--async` flag for solution imports to avoid timeouts

# AGENTS.md

## Project Overview
Power Platform solution repository for CustomerPortal — a Dynamics 365 Customer Service
customization including model-driven apps, PCF controls, and Power Automate flows.

## Technology Stack
- Power Platform CLI (PAC CLI) for ALM operations
- TypeScript + React for PCF controls (Fluent UI v9 component library)
- GitHub Actions for CI/CD pipelines
- Dataverse as the data platform
- Node.js 20 for scripts and tests

## Environment Naming
- Development: DEV-CustomerPortal (https://devenv.crm.dynamics.com)
- Test: TEST-CustomerPortal (https://testenv.crm.dynamics.com)
- Production: PROD-CustomerPortal (https://prodenv.crm.dynamics.com)

## Branching Strategy
- `main` → triggers export from DEV and commits unpacked solution
- `release/*` → triggers import to TEST with Solution Checker gate
- Tags `v*` → triggers production import (manual approval required)

## Conventions
- Solution unique name: CustomerPortal
- PCF controls namespace: ELCA.CustomerPortal
- Always run `pac solution check` before importing to TEST or PROD
- Use `--async` flag for solution imports to avoid timeouts

.github/copilot/config.json — pre-approved tools and marketplace registration

{
  "marketplaces": [
    "microsoft/power-platform-skills",
    "github/awesome-copilot"
  ],
  "allowedTools": [
    "shell(pac *)",
    "shell(npm *)",
    "shell(dotnet *)",
    "shell(git *)",
    "shell(bash scripts/*)"
  ],
  "launchMessage": "CustomerPortal Power Platform project. PAC CLI, npm, dotnet, and git are pre-approved. Run /skills to see available Power Platform skills."
}

{
  "marketplaces": [
    "microsoft/power-platform-skills",
    "github/awesome-copilot"
  ],
  "allowedTools": [
    "shell(pac *)",
    "shell(npm *)",
    "shell(dotnet *)",
    "shell(git *)",
    "shell(bash scripts/*)"
  ],
  "launchMessage": "CustomerPortal Power Platform project. PAC CLI, npm, dotnet, and git are pre-approved. Run /skills to see available Power Platform skills."
}

Security note: Only pre-approve tools with a limited blast radius. shell(pac *) is safe — PAC CLI cannot damage files outside your Dataverse environment. Avoid shell(rm *) or shell(curl *) in shared config files.

Working with Agent Skills

Agent Skills are the most powerful customization mechanism in Copilot CLI. A skill is a folder containing a SKILL.md file that packages domain knowledge, workflow instructions, and optional scripts into a reusable unit the agent loads automatically when relevant.

How skills are discovered and loaded

The agent always reads skill names and descriptions from YAML frontmatter — this is lightweight and happens on every session. The full skill body is only loaded when the agent decides it is relevant to your current task. This means you can have many skills installed without paying context cost for all of them at once.

Session start → Load skill metadata (name + description for all installed skills)
               ↓
User prompt → Agent matches prompt to relevant skills
               ↓
Relevant skill → Full SKILL.md body loaded into context
               ↓
Agent follows skill instructions for the task

Session start → Load skill metadata (name + description for all installed skills)
               ↓
User prompt → Agent matches prompt to relevant skills
               ↓
Relevant skill → Full SKILL.md body loaded into context
               ↓
Agent follows skill instructions for the task

Skill storage locations

Writing your first skill

The minimum viable skill is a folder with a SKILL.md file:

.github/skills/
└── pac-cli-deploy/
    └── SKILL.md

.github/skills/
└── pac-cli-deploy/
    └── SKILL.md

---
name: pac-cli-deploy
description: Deploy Power Platform solutions using PAC CLI. Use when the user asks to
  export, import, pack, unpack, or publish a Dataverse solution, or when working with
  PAC CLI authentication and environment management.
---

# PAC CLI Deployment Skill

## Authentication
Always use the service principal profile:
```bash
pac auth create --url $DATAVERSE_URL --applicationId $CLIENT_ID \
  --clientSecret $CLIENT_SECRET --tenant $TENANT_ID
```

## Pre-import checklist
1. Run `pac solution check --solutionFile <path>` — block on Critical issues
2. For TEST/PROD: confirm version bump in solution.xml
3. Use `--async` flag for solutions > 50MB

## Environment URLs
- DEV: https://devenv.crm.dynamics.com
- TEST: https://testenv.crm.dynamics.com
- PROD: https://prodenv.crm.dynamics.com (requires approval workflow)

---
name: pac-cli-deploy
description: Deploy Power Platform solutions using PAC CLI. Use when the user asks to
  export, import, pack, unpack, or publish a Dataverse solution, or when working with
  PAC CLI authentication and environment management.
---

# PAC CLI Deployment Skill

## Authentication
Always use the service principal profile:
```bash
pac auth create --url $DATAVERSE_URL --applicationId $CLIENT_ID \
  --clientSecret $CLIENT_SECRET --tenant $TENANT_ID
```

## Pre-import checklist
1. Run `pac solution check --solutionFile <path>` — block on Critical issues
2. For TEST/PROD: confirm version bump in solution.xml
3. Use `--async` flag for solutions > 50MB

## Environment URLs
- DEV: https://devenv.crm.dynamics.com
- TEST: https://testenv.crm.dynamics.com
- PROD: https://prodenv.crm.dynamics.com (requires approval workflow)

The description field is critical — it is the primary mechanism by which the agent decides whether to load the skill for a given prompt. Write it to be specific and include trigger phrases.

Invoking skills explicitly

You can also manually trigger a skill with a slash command:

> /pac-cli-deploy Export the latest CustomerPortal solution to the solutions/ folder

> /pac-cli-deploy Export the latest CustomerPortal solution to the solutions/ folder

Installing Skills for Your Developer Profile

The Agent Skills standard (agentskills.io) is supported across GitHub Copilot CLI, Claude Code, VS Code agent mode, and several other tools. Skills you install work in all of them simultaneously. Below is a curated selection by developer role.

Install rule: Aim for 4–8 skills per project. Installing too many causes “context rot” — the agent uses context on loading skill metadata instead of your actual task.

Install commands

# Register marketplaces
/plugin marketplace add microsoft/power-platform-skills
/plugin marketplace add github/awesome-copilot
/plugin marketplace add microsoft/skills

# Install specific plugins
/plugin install power-pages@power-platform-skills
/plugin install model-apps@power-platform-skills

# For microsoft/skills (uses npm wizard)
npx skills add microsoft/skills
# → interactive selector lets you choose exactly which skills to install

# Register marketplaces
/plugin marketplace add microsoft/power-platform-skills
/plugin marketplace add github/awesome-copilot
/plugin marketplace add microsoft/skills

# Install specific plugins
/plugin install power-pages@power-platform-skills
/plugin install model-apps@power-platform-skills

# For microsoft/skills (uses npm wizard)
npx skills add microsoft/skills
# → interactive selector lets you choose exactly which skills to install

Power Platform Developers

⚠️ Important: microsoft/power-platform-skills currently ships only two plugins — power-pages and model-apps. There is no PCF plugin in this repository. PCF coverage exists in github/awesome-copilot but as instructions and collections, not Agent Skills. See the distinction in the table below.

From microsoft/power-platform-skills (Agent Skills / Plugins):

From github/awesome-copilot — Agent Skills:

From github/awesome-copilot — Instructions (.instructions.md, always-on pattern-matched context):

Instructions load differently from skills. They are pattern-matched against file types or folder paths and injected automatically — they don’t require a description-triggered invocation like skills do.

From github/awesome-copilot — Collections (curated multi-item toolkits):

.NET Developers

Microsoft’s microsoft/skills repository has 29 .NET-specific skills, all with test coverage and acceptance criteria.

From microsoft/skills:

From github/awesome-copilot skills:

Available collections:

React / TypeScript Developers

From anthropics/skills:

From microsoft/skills:

Available collections:

Azure / DevOps Developers / Engineers

From microsoft/skills:

From github/awesome-copilot skills:

MCP Server Builders

From microsoft/skills:

From github/awesome-copilot collections (one per language):

Cross-Role Productivity (Useful for Everyone)

From anthropics/skills:

From github/awesome-copilot skills:

Extending with MCP Servers

MCP (Model Context Protocol) servers allow Copilot CLI to interact with external systems — reading live Dataverse metadata, querying your database, calling APIs — as part of its reasoning and execution.

Copilot CLI ships with GitHub’s own MCP server pre-configured, enabling native operations against your repositories, issues, pull requests, and Actions workflows.

Adding a custom MCP server

Edit ~/.copilot/mcp-config.json (or use /settings → MCP in the interactive UI):

{
  "mcpServers": {
    "dataverse": {
      "command": "node",
      "args": ["/path/to/dataverse-mcp-server/dist/index.js"],
      "env": {
        "DATAVERSE_URL": "https://yourorg.crm.dynamics.com",
        "CLIENT_ID": "your-app-registration-client-id",
        "TENANT_ID": "your-tenant-id",
        "CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

{
  "mcpServers": {
    "dataverse": {
      "command": "node",
      "args": ["/path/to/dataverse-mcp-server/dist/index.js"],
      "env": {
        "DATAVERSE_URL": "https://yourorg.crm.dynamics.com",
        "CLIENT_ID": "your-app-registration-client-id",
        "TENANT_ID": "your-tenant-id",
        "CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

What a Dataverse MCP server enables

Once configured, natural language queries against your live environment become possible:

> Check the Contact entity and list all custom fields added in the last 30 days.
  Then generate a PAC CLI command to export only the solution containing those components.

> Check the Contact entity and list all custom fields added in the last 30 days.
  Then generate a PAC CLI command to export only the solution containing those components.

The agent calls the MCP server, retrieves live entity metadata, cross-references solution components, and generates a scoped pac solution export command — in one session.

Available community MCP servers for Power Platform

• Dataverse MCP server — Entity metadata, OData queries, solution component inspection
• Copilot Studio MCP server — Agent definition management, topic inspection (use the copilot-studio-mcp-server skill to scaffold this)
• GitHub MCP server (built-in) — Issues, PRs, branches, Actions workflows, code search

Power Platform Integration: Step-by-Step

This is the complete setup sequence for a Power Platform developer starting fresh with a Dataverse project repository.

Step 1: Install Copilot CLI and authenticate

npm install -g @github/copilot
copilot
# → Browser-based GitHub auth on first run

npm install -g @github/copilot
copilot
# → Browser-based GitHub auth on first run

Step 2: Navigate to your Power Platform repo and initialize

cd ~/repos/CustomerPortal
copilot
/init
# → Generates AGENTS.md with repo context analysis

cd ~/repos/CustomerPortal
copilot
/init
# → Generates AGENTS.md with repo context analysis

Inspect the generated AGENTS.md and add your environment URLs, branching strategy, and PAC CLI conventions.

Step 3: Add the Power Platform Skills marketplace

/plugin marketplace add microsoft/power-platform-skills
/plugin install power-pages@power-platform-skills

/plugin marketplace add microsoft/power-platform-skills
/plugin install power-pages@power-platform-skills

For model-driven app development:

/plugin install model-apps@power-platform-skills

/plugin install model-apps@power-platform-skills

Step 4: Create your project config file

Create .github/copilot/config.json in your repository:

{
  "marketplaces": ["microsoft/power-platform-skills"],
  "allowedTools": [
    "shell(pac *)",
    "shell(npm *)",
    "shell(dotnet *)",
    "shell(git *)"
  ],
  "launchMessage": "CustomerPortal Power Platform project loaded. PAC CLI pre-approved."
}

{
  "marketplaces": ["microsoft/power-platform-skills"],
  "allowedTools": [
    "shell(pac *)",
    "shell(npm *)",
    "shell(dotnet *)",
    "shell(git *)"
  ],
  "launchMessage": "CustomerPortal Power Platform project loaded. PAC CLI pre-approved."
}

Step 5: Add Power Platform-specific skills

# Create the skills folder
mkdir -p .github/skills/pac-cli-deploy

# Create your first skill (see the template in section 8)
# Then verify it is discovered
/skills

# Create the skills folder
mkdir -p .github/skills/pac-cli-deploy

# Create your first skill (see the template in section 8)
# Then verify it is discovered
/skills

You should see your pac-cli-deploy skill listed with its description.

Step 6: Configure your Dataverse MCP server (optional but recommended)

If you have a Dataverse MCP server available, configure it in ~/.copilot/mcp-config.json as shown in section 10. This unlocks live environment queries during your sessions.

Step 7: Try your first Power Platform prompt

> List all solutions in our dev environment, show their versions, 
  and flag any that are more than 2 minor versions behind main

> List all solutions in our dev environment, show their versions, 
  and flag any that are more than 2 minor versions behind main

With the MCP server configured, Copilot CLI calls Dataverse directly. Without it, it works from the files in your repository.

Practical Workflows with Code Examples

Workflow 1: Scaffold a new PAC CLI Power Platform repository

copilot
> Set up a Power Platform ALM repository for a Dataverse solution named "CustomerPortal".
> Include:
> - PAC CLI commands for solution export and import
> - GitHub Actions workflows for CI/CD across dev, test, and prod environments
> - A .env.example file with all required variables
> - An AGENTS.md with Power Platform project context

copilot
> Set up a Power Platform ALM repository for a Dataverse solution named "CustomerPortal".
> Include:
> - PAC CLI commands for solution export and import
> - GitHub Actions workflows for CI/CD across dev, test, and prod environments
> - A .env.example file with all required variables
> - An AGENTS.md with Power Platform project context

Copilot switches to Plan Mode, proposes the full structure for review, then executes. The generated export workflow:

# .github/workflows/export-solution.yml
name: Export Power Platform Solution

on:
  workflow_dispatch:
    inputs:
      solution_name:
        description: 'Solution unique name'
        required: true
        default: 'CustomerPortal'

jobs:
  export-solution:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install PAC CLI
        run: npm install -g @microsoft/powerplatform-cli

      - name: Authenticate to Power Platform
        run: |
          pac auth create \
            --url ${{ secrets.DEV_DATAVERSE_URL }} \
            --applicationId ${{ secrets.CLIENT_ID }} \
            --clientSecret ${{ secrets.CLIENT_SECRET }} \
            --tenant ${{ secrets.TENANT_ID }}

      - name: Export solution (unmanaged)
        run: |
          pac solution export \
            --name ${{ github.event.inputs.solution_name }} \
            --path ./solutions/${{ github.event.inputs.solution_name }}.zip \
            --managed false --overwrite true

      - name: Unpack solution
        run: |
          pac solution unpack \
            --zipfile ./solutions/${{ github.event.inputs.solution_name }}.zip \
            --folder ./solutions/${{ github.event.inputs.solution_name }} \
            --processCanvasApps true

      - name: Commit unpacked solution
        run: |
          git config user.name "GitHub Actions"
          git config user.email "actions@github.com"
          git add ./solutions/
          git commit -m "chore: export ${{ github.event.inputs.solution_name }}" || echo "No changes"
          git push

# .github/workflows/export-solution.yml
name: Export Power Platform Solution

on:
  workflow_dispatch:
    inputs:
      solution_name:
        description: 'Solution unique name'
        required: true
        default: 'CustomerPortal'

jobs:
  export-solution:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install PAC CLI
        run: npm install -g @microsoft/powerplatform-cli

      - name: Authenticate to Power Platform
        run: |
          pac auth create \
            --url ${{ secrets.DEV_DATAVERSE_URL }} \
            --applicationId ${{ secrets.CLIENT_ID }} \
            --clientSecret ${{ secrets.CLIENT_SECRET }} \
            --tenant ${{ secrets.TENANT_ID }}

      - name: Export solution (unmanaged)
        run: |
          pac solution export \
            --name ${{ github.event.inputs.solution_name }} \
            --path ./solutions/${{ github.event.inputs.solution_name }}.zip \
            --managed false --overwrite true

      - name: Unpack solution
        run: |
          pac solution unpack \
            --zipfile ./solutions/${{ github.event.inputs.solution_name }}.zip \
            --folder ./solutions/${{ github.event.inputs.solution_name }} \
            --processCanvasApps true

      - name: Commit unpacked solution
        run: |
          git config user.name "GitHub Actions"
          git config user.email "actions@github.com"
          git add ./solutions/
          git commit -m "chore: export ${{ github.event.inputs.solution_name }}" || echo "No changes"
          git push

Workflow 2: Scaffold a PCF control

copilot --allow-tool 'shell(pac *)' --allow-tool 'shell(npm *)'
> Scaffold a new PCF control named "StakeholderMap" using pac pcf init.
> It should be a TypeScript field control for Dataverse.
> After scaffolding, install dependencies and confirm it builds cleanly.

copilot --allow-tool 'shell(pac *)' --allow-tool 'shell(npm *)'
> Scaffold a new PCF control named "StakeholderMap" using pac pcf init.
> It should be a TypeScript field control for Dataverse.
> After scaffolding, install dependencies and confirm it builds cleanly.

Copilot CLI runs the PAC CLI commands, installs dependencies, runs npm run build, interprets TypeScript compiler output, and iterates on any errors before handing back to you.

Sample manifest produced:

<!-- ControlManifest.Input.xml -->
<manifest>
  <control namespace="AIDevMe" constructor="StakeholderMap"
           version="1.0.0" display-name-key="StakeholderMap_DisplayName"
           control-type="standard">
    <property name="stakeholderData" of-type="Multiple" usage="bound" required="true"/>
    <resources>
      <code path="index.ts" order="1"/>
      <css path="css/StakeholderMap.css" order="1"/>
    </resources>
  </control>
</manifest>

<!-- ControlManifest.Input.xml -->
<manifest>
  <control namespace="AIDevMe" constructor="StakeholderMap"
           version="1.0.0" display-name-key="StakeholderMap_DisplayName"
           control-type="standard">
    <property name="stakeholderData" of-type="Multiple" usage="bound" required="true"/>
    <resources>
      <code path="index.ts" order="1"/>
      <css path="css/StakeholderMap.css" order="1"/>
    </resources>
  </control>
</manifest>

Workflow 3: Debug a failing GitHub Actions pipeline

copilot
> My GitHub Actions workflow is failing on the 'pac solution export' step with:
> "Error: Solution with name 'MyApp' was not found in the target environment."
> The solution definitely exists. The workflow uses a Service Principal.
> Here's the workflow: [paste content or use /add-file .github/workflows/export.yml]

copilot
> My GitHub Actions workflow is failing on the 'pac solution export' step with:
> "Error: Solution with name 'MyApp' was not found in the target environment."
> The solution definitely exists. The workflow uses a Service Principal.
> Here's the workflow: [paste content or use /add-file .github/workflows/export.yml]

Copilot reads the workflow and identifies the most common cause — the DATAVERSE_URL secret resolving to the wrong environment. It proposes a fix and shows a /diff before applying:

# ❌ Common mistake: ambiguous secret name can resolve to wrong environment
- run: pac auth create --url ${{ secrets.DATAVERSE_URL }}

# ✅ Fix: use environment-scoped secrets
- run: pac auth create --url ${{ secrets.DEV_DATAVERSE_URL }}

# ❌ Common mistake: ambiguous secret name can resolve to wrong environment
- run: pac auth create --url ${{ secrets.DATAVERSE_URL }}

# ✅ Fix: use environment-scoped secrets
- run: pac auth create --url ${{ secrets.DEV_DATAVERSE_URL }}

Workflow 4: Write integration tests for a Power Automate flow

# Use background delegation — write tests while you keep working
> & Write a Node.js Jest integration test suite for our LeadQualification 
  Power Automate HTTP trigger flow. Include happy path, missing field validation,
  and invalid email tests. Use the FLOW_URL from .env.

# Continue working in the terminal, then later:
/resume

# Use background delegation — write tests while you keep working
> & Write a Node.js Jest integration test suite for our LeadQualification 
  Power Automate HTTP trigger flow. Include happy path, missing field validation,
  and invalid email tests. Use the FLOW_URL from .env.

# Continue working in the terminal, then later:
/resume

Sample generated test:

// lead-qualification.test.js
const axios = require("axios");
require("dotenv").config();

const FLOW_URL = process.env.LEAD_QUALIFICATION_FLOW_URL;

describe("LeadQualification Power Automate Flow", () => {

  test("Valid payload returns 202 with leadId", async () => {
    const response = await axios.post(FLOW_URL, {
      firstName: "Anna", lastName: "Kovacs",
      email: "anna.kovacs@example.com", company: "Contoso Ltd"
    });
    expect(response.status).toBe(202);
    expect(response.data).toHaveProperty("leadId");
  });

  test("Missing lastName returns 400", async () => {
    await expect(
      axios.post(FLOW_URL, { firstName: "Anna", email: "a@b.com", company: "Contoso" })
    ).rejects.toMatchObject({ response: { status: 400 } });
  });

  test("Invalid email format returns 400", async () => {
    await expect(
      axios.post(FLOW_URL, {
        firstName: "Anna", lastName: "Kovacs",
        email: "not-an-email", company: "Contoso"
      })
    ).rejects.toMatchObject({ response: { status: 400 } });
  });
});

// lead-qualification.test.js
const axios = require("axios");
require("dotenv").config();

const FLOW_URL = process.env.LEAD_QUALIFICATION_FLOW_URL;

describe("LeadQualification Power Automate Flow", () => {

  test("Valid payload returns 202 with leadId", async () => {
    const response = await axios.post(FLOW_URL, {
      firstName: "Anna", lastName: "Kovacs",
      email: "anna.kovacs@example.com", company: "Contoso Ltd"
    });
    expect(response.status).toBe(202);
    expect(response.data).toHaveProperty("leadId");
  });

  test("Missing lastName returns 400", async () => {
    await expect(
      axios.post(FLOW_URL, { firstName: "Anna", email: "a@b.com", company: "Contoso" })
    ).rejects.toMatchObject({ response: { status: 400 } });
  });

  test("Invalid email format returns 400", async () => {
    await expect(
      axios.post(FLOW_URL, {
        firstName: "Anna", lastName: "Kovacs",
        email: "not-an-email", company: "Contoso"
      })
    ).rejects.toMatchObject({ response: { status: 400 } });
  });
});

Workflow 5: Use Dataverse MCP for live environment queries

With a Dataverse MCP server configured (Extending with MCP Servers):

> Check the Contact entity in our dev environment and list all custom fields
  added in the last 30 days. Generate a PAC CLI command to export only
  the solution containing those components.

> Check the Contact entity in our dev environment and list all custom fields
  added in the last 30 days. Generate a PAC CLI command to export only
  the solution containing those components.

The agent calls Dataverse, retrieves metadata, cross-references solution components, and produces:

pac solution export \
  --name ContactCustomizations_20260205 \
  --path ./solutions/ContactCustomizations_20260205.zip \
  --managed false

pac solution export \
  --name ContactCustomizations_20260205 \
  --path ./solutions/ContactCustomizations_20260205.zip \
  --managed false

Copilot CLI vs Claude Code

Both are terminal-native AI coding agents that share the same Agent Skills standard and plugin ecosystem. Here is how they compare for Power Platform professionals.

When to choose Copilot CLI: Your workflow is deeply embedded in GitHub — assigning issues to agents, reviewing PRs, triggering Actions. You want multi-model flexibility within one tool. Your organization manages everything through GitHub org policies.

When to choose Claude Code: You want the largest raw context window. You prefer direct Anthropic model access. You value the built-in document creation skills without any plugin setup.

For most Power Platform enterprise architects: use both. They share the same skills and plugins — a skill you write today works in both tools without modification.

Enterprise Setup for Administrators

Enabling Copilot CLI for your organization

For Copilot Business and Enterprise plans, an administrator must explicitly enable Copilot CLI from the GitHub organization settings page before users can access it.

Path: GitHub Organization Settings → Copilot → Features→ Enable Copilot CLI

Enterprise controls available at GA

Recommended enterprise configuration for Power Platform teams

1. Enable Copilot CLI at the org level with Copilot Business or Enterprise.
2. Allow PAC CLI, npm, and git in the organization policy default tool list.
3. Register microsoft/power-platform-skills as the default marketplace in a shared .github/copilot/config.json committed to all Power Platform repos.
4. Set model policy to Sonnet 4.6 as the default, with Opus 4.6 available on request — this balances capability and cost.
5. Enable audit logging before rolling out to large teams — you want session data from the start.
6. For GCC / on-premise Dataverse: confirm HTTPS proxy routes are configured for api.github.com and Anthropic/OpenAI endpoints before rollout

What’s Next — And How to Stay Sharp

This guide covers everything you need to get productive with Copilot CLI today. But the ecosystem is moving fast — new skills are being published weekly, MCP server support is expanding, and Microsoft is actively adding plugins to microsoft/power-platform-skills.

Here’s how to keep up:

• ⭐ Star the repos — microsoft/power-platform-skills, github/awesome-copilot, and microsoft/skills on GitHub. Watch for new releases.
• Subscribe to AIDevMe — every deep-dive article on agentic Power Platform development, agent skills, and MCP patterns lands in your inbox before it’s shared anywhere else. Subscribe here.
• Tell me what’s missing — Is there a step in this guide that needs more detail? A workflow we didn’t cover? A skill that should be in the curated lists? Leave a comment on the companion article or open an issue — this guide is a living document.
• Share with your team — If you’re the one who discovered this, you’re probably the one who’ll set it up for everyone else too. Forward this guide to the developers on your team who work with PAC CLI, PCF, or Dataverse — it’ll save them hours.

References and Further Reading

Companion Article

This guide is the hands-on companion to the AIDevMe blog article covering the GitHub Copilot CLI GA announcement. If you prefer a narrative overview — what changed, why it matters, enterprise readiness considerations, and a Copilot CLI vs Claude Code comparison — start there first.

→ GitHub Copilot CLI Is Now Generally Available — And Power Platform Developers Should Pay Attention — Published on AIDevMe.com

• GitHub Changelog: Copilot CLI is now generally available — Official GA announcement, February 25, 2026
• GitHub Copilot CLI Documentation — Full reference documentation
• Copilot CLI Best Practices Guide — GitHub’s official recommendations
• About Agent Skills — GitHub Docs
• Agent Skills specification — The open standard
• microsoft/power-platform-skills — Official Microsoft plugin for Copilot CLI and Claude Code
• microsoft/skills — 132 Azure SDK skills with 1-click install wizard
• github/awesome-copilot — Community skills, agents, instructions, and plugins
• anthropics/skills — Anthropic’s reference skills including document creation
• Enterprise AI Controls & Agent Control Plane GA — Enterprise governance features
• PAC CLI Reference — Microsoft Learn