/deploy-site

name: deploy-site
description: >-
  Deploys an existing Power Pages site to a Power Pages environment using PAC CLI. Routes SPA
  sites to the existing build and upload-code-site workflow, and PAC-downloaded non-SPA (classic)
  sites to an isolated upload workflow with explicit data-model and website-identity checks. Handles
  tooling verification, authentication, environment confirmation, upload approval, and
  verification. Use when the user wants to deploy, upload, publish, or push either site type.
user-invocable: true
allowed-tools: Read, Bash, AskUserQuestion, Glob, Grep, TaskCreate, TaskUpdate, TaskList
model: sonnet

> **Plugin check**: Run `node "${PLUGIN_ROOT}/scripts/check-version.js"` — if it outputs a message, show it to the user before proceeding.

Deploy Power Pages Site

Route to the correct deployment workflow before running SPA build, attachment, or activation logic.

Core Principles

• **Verify before acting**: Always confirm PAC CLI availability, authentication status, and the target environment before attempting any deployment.
• **Use TaskCreate/TaskUpdate**: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.
• **Never change environment settings without consent**: If deployment requires modifying environment configuration (e.g., unblocking JavaScript attachments), always explain the change and get explicit user permission first.

**Initial request:** $ARGUMENTS

---

Site-Type Routing

Classify explicit request signals first:

• React, Vue, Angular, Astro, SPA, code site, or `powerpages.config.json` → **SPA site**
• non-SPA, classic, traditional, declarative, Enhanced, EDM, Standard data model, `.portalconfig`,

or `website.yml` → **Non-SPA site**

When the request is not explicit, search the current workspace for:

• SPA roots containing `powerpages.config.json`;
• non-SPA roots containing both `.portalconfig/` and `website.yml`, including a nested

`.powerpages-site/`.

Exclude dependency, build-output, temporary, generated-output, and version-control directories. Use request paths and the current directory to resolve one project. Never choose the first result arbitrarily.

<!-- gate: deploy-site:0.project-type | category=plan | cancel-leaves=nothing -->

> 🚦 **Gate (plan · deploy-site:0.project-type):** Select the exact project when SPA and > non-SPA sites, or multiple valid roots, remain possible. > > **Trigger:** Project type or root is ambiguous after discovery. > **Why:** The two site types require incompatible PAC upload commands. > **Cancel leaves:** Nothing; no build or upload has started.

If ambiguous, use `AskUserQuestion` to select the exact project root and detected type.

• **Non-SPA site:** Read and follow

`${PLUGIN_ROOT}/skills/deploy-site/workflows/non-spa-site.md`. Do not continue into the SPA phases below.

• **SPA site:** Continue with the existing workflow below.

Non-SPA upload approval

The authoritative markers and prompts live in `workflows/non-spa-site.md`. Gate `deploy-site:non-spa-4.permissions-audit` handles permission-sensitive changes before upload. Gate `deploy-site:non-spa-5.upload` approves the exact root, environment, website identity, model, and local change summary immediately before upload.

SPA-Site Deployment Workflow

The following phases retain the existing SPA behavior.

---

Phase 1: Verify PAC CLI

**Goal**: Ensure PAC CLI is installed and available on the system PATH

**Actions**:

1. Create todo list with all 6 phases (see [Progress Tracking](#progress-tracking) table) 2. Run `pac help` to check if the PAC CLI is installed and available on the system PATH.

   pac help

3. **If the command succeeds**: PAC CLI is installed. Proceed to Phase 2.

4. **If the command fails** (command not found / not recognized):

1. Inform the user that PAC CLI is required but not installed. 2. Fetch installation instructions from `https://aka.ms/PowerPlatformCLI` using the following approach:

• Tell the user: "PAC CLI is not installed. You can install it by running:"

        dotnet tool install --global Microsoft.PowerApps.CLI.Tool

• If `dotnet` is also not available, direct the user to <https://aka.ms/PowerPlatformCLI> for full installation instructions including .NET SDK setup.

3. After installation, verify by running `pac help` again. 4. If it still fails, stop and ask the user to resolve the installation manually.

**Output**: PAC CLI installed and verified

---

Phase 2: Verify Authentication

**Goal**: Ensure the user is authenticated with PAC CLI and has a valid session

**Actions**:

1. Run `pac auth who` to check the current authentication status.

   pac auth who

2. **If authenticated**: Extract the following values from the output:

• **Environment name** and **URL**
• **Environment ID** — the GUID after `Environment ID:`
• **Cloud** — the value after `Cloud:` (e.g., `Public`, `UsGov`, `UsGovHigh`, `UsGovDod`, `China`)

Proceed to Phase 3.

3. **If not authenticated**:

1. Inform the user they are not authenticated with PAC CLI.

<!-- not-a-gate: free-text env URL fallback when PAC CLI auth is missing — data-gathering, no destructive action -->

2. Use `AskUserQuestion` to ask for the environment URL:

| Question | Header | Options | |----------|--------|---------| | You are not authenticated with PAC CLI. Please provide your Power Pages environment URL (e.g., `https://org12345.crm.dynamics.com`) so I can authenticate you. | Auth | *(free text input via "Other")* |

Provide two placeholder options to guide the user:

• "I'll paste the URL" (description: "Select 'Other' below and paste your environment URL")
• "I don't know my URL" (description: "You can find it in the Power Platform admin center under Environments > your environment > Environment URL")

3. Once the user provides the