# Deploy Site

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-microsoft-power-platform-skills-deploy-site`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [microsoft](https://agentstack.voostack.com/s/microsoft)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [microsoft](https://github.com/microsoft)
- **Source:** https://github.com/microsoft/power-platform-skills/tree/main/plugins/power-pages/skills/deploy-site
- **Website:** https://aka.ms/ppskills

## Install

```sh
agentstack add skill-microsoft-power-platform-skills-deploy-site
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

> **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 Code Site

Guide the user through deploying an existing Power Pages code site to a Power Pages environment using PAC CLI. Follow a systematic approach: verify tooling, authenticate, confirm the target environment, build and upload the site, and handle any blockers.

## 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

---

## 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.

   ```bash
   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:"

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

      - If `dotnet` is also not available, direct the user to  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.

   ```bash
   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.

   

   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 URL, run the authentication command:

      ```bash
      pac auth create --environment ""
      ```

      This will open a browser window for the user to sign in.

   4. After the command completes, verify by running `pac auth who` again.
   5. If authentication succeeds, proceed to Phase 3.
   6. If authentication fails, present the error to the user and help them troubleshoot.

**Output**: Authenticated PAC CLI session with environment name and URL extracted

---

## Phase 3: Confirm Environment

**Goal**: Ensure the user is deploying to the correct target environment

**Actions**:

> 🚦 **Gate (consent · deploy-site:3.confirm-env):** Echo the current environment and require explicit confirmation before any upload. Covers the follow-up "pick a different env" sub-prompt in the same section — wrong-env deploys are the #1 destructive shared-state failure for this skill, so this gate must fire even when PAC CLI shows a recognizable env.
>
> **Trigger:** Phase 3 entry; environment resolved from PAC CLI.
> **Why we ask:** Site uploaded to wrong tenant / wrong env — committed to a Dataverse instance the user did not intend; cleanup requires manual deletion or another deploy from a different env.
> **Cancel leaves:** Nothing — no upload fired.

1. Present the current environment information to the user and ask them to confirm.

   Use `AskUserQuestion` with the following structure:

   | Question | Header | Options |
   |----------|--------|---------|
   | You are currently connected to environment: **** (). Do you want to deploy to this environment? | Environment | Yes, use this environment, No, let me choose a different one |

2. **If "Yes, use this environment"**: Proceed to Phase 4.

3. **If "No, let me choose a different one"**:

   1. Run `pac org list` to retrieve all available environments:

      ```bash
      pac org list
      ```

   2. Parse the output to extract environment names and URLs.
   3. Use `AskUserQuestion` to present the available environments as options (pick up to 4 most relevant, or let user specify).
   4. Once the user selects an environment, switch to it:

      ```bash
      pac org select --environment ""
      ```

   5. Verify the switch by running `pac auth who` again.

**Output**: Confirmed target environment for deployment

---

## Phase 4: Deploy the Code Site

**Goal**: Locate the project, build it, and upload to Power Pages

**Actions**:

### 4.1 Locate the Project Root

Determine the project root directory. The project root is the directory containing `powerpages.config.json`. Use `Glob` to search for it:

```text
**/powerpages.config.json
```

> 🚦 **Gate (plan · deploy-site:4.1.multi-project):** More than one `powerpages.config.json` candidate found — pick the right project to deploy.
>
> **Trigger:** Phase 4.1 glob returned multiple matches.
> **Why we ask:** Wrong project uploaded — pollutes the target env with files from a different site.
> **Cancel leaves:** Nothing — no upload fired.

If found in the current working directory or a subdirectory, use that directory as `PROJECT_ROOT`. If multiple are found, ask the user which one to deploy using `AskUserQuestion`.

If not found, ask the user to provide the path to the project root.

### 4.2 Offer Permissions Audit (Redeployments Only)

If `.powerpages-site` already exists (i.e., this is not the first deployment), table permissions and site settings may have drifted from the code since the last deployment. Offer to audit before deploying.

> 🚦 **Gate (plan · deploy-site:4.2.audit-permissions):** Re-deployment detected — offer to run `/audit-permissions` to catch drift between code and table permissions before push.
>
> **Trigger:** `.powerpages-site` exists (not first deployment).
> **Why we ask:** Stale permission YAML deploys, causing 403s for users until next audit run.
> **Cancel leaves:** Nothing — audit is read-only; declining just proceeds to build + upload.

Use `AskUserQuestion`:

| Question | Header | Options |
|----------|--------|---------|
| This site has been deployed before. Would you like to run a permissions audit to verify table permissions match your current code before deploying? | Audit | Yes, audit permissions (Recommended), Skip — permissions are up to date |

**If "Yes"**: Invoke `/audit-permissions` to run the audit. After the audit completes, resume with Step 4.3.
**If "Skip"**: Proceed to Step 4.3.

If `.powerpages-site` does **not** exist (first deployment), skip this step — there are no existing permissions to audit.

### 4.3 Build the Site

Before uploading, ensure the site is built:

```bash
cd ""
npm run build
```

If the build fails, stop and help the user fix the build errors before retrying.

### 4.4 Upload to Power Pages

Run the upload command:

```bash
pac pages upload-code-site --rootPath ""
```

**If the upload succeeds**: Proceed to Phase 5 to verify the deployment.

**If the upload fails**: Check the error message:

- If the failure is related to **blocked JavaScript** (`.js`) attachments → proceed to **Phase 6**
- If the failure mentions **`.html` type attachments are currently blocked** → this is a **misleading error**. See [Troubleshooting: HTML Blocked Attachment Error](#troubleshooting-html-blocked-attachment-error) below
- For other errors → present the error to the user and help them troubleshoot

**Output**: Site built and uploaded to Power Pages

---

## Phase 5: Verify Deployment

**Goal**: Confirm the deployment was successful and handle post-deployment steps

**Actions**:

### 5.1 Verify `.powerpages-site` Folder

Confirm `.powerpages-site` exists and list its contents (`web-roles/`, `site-settings/`, `table-permissions/`).

### 5.2 Record Skill Usage

> Reference: `${PLUGIN_ROOT}/references/skill-tracking-reference.md`

Follow the skill tracking instructions in the reference to record this skill's usage. Use `--skillName "DeploySite"`.

### 5.3 Confirm Upload Output

Review the output from the `pac pages upload-code-site` command in Phase 4 (or Phase 6 retry). Verify it reported a successful upload with no errors.

### 5.4 Commit Changes

Stage and commit deployment artifacts:

```bash
git add -A
git commit -m "Deploy site to Power Pages"
```

### 5.5 Check Activation Status

Run the activation status check:

```bash
node "${PLUGIN_ROOT}/scripts/check-activation-status.js" --projectRoot ""
```

Evaluate the JSON result:

- **If `activated` is `true`**: Inform the user their site is already activated (show `websiteUrl` if present). Proceed to step 5.6, then skip to [Suggest Next Steps](#suggest-next-steps). Do NOT ask about activation.
- **If `activated` is `false`**: Proceed to step 5.5.1.
- **If `error` is present**: Fall back to step 5.5.1. Do not block the deployment flow.

#### 5.5.1 Ask About Activation (only if site is NOT already activated)

> 🚦 **Gate (plan · deploy-site:5.5.1.activate):** Site deployed but not yet activated — offer to invoke `/activate-site` to provision the subdomain.
>
> **Trigger:** Phase 5.5 detected `activated:false` on a fresh deploy.
> **Why we ask:** Auto-activating writes the wrong subdomain (permanent for the site); auto-skipping leaves the site without a live URL.
> **Cancel leaves:** Nothing — no activation API call fired.

Ask the user if they want to activate the site using `AskUserQuestion`:

| Question | Header | Options |
|----------|--------|---------|
| Site deployed successfully! Would you like to activate (provision) the site now so it gets a live URL? | Activate | Activate now (Recommended) — Provision the site with a subdomain and make it live, Skip for now — I'll activate later |

**If "Activate now"**: Invoke the `/activate-site` skill. After activation completes, proceed to step 5.6 to clear the site cache.
**If "Skip for now"**: Suggest next steps (see [Suggest Next Steps](#suggest-next-steps)).

### 5.6 Clear Site Cache (Only If Activated)

After confirming the site is activated (either it was already activated in step 5.5, or the user just activated it in step 5.5.1), offer to clear the runtime cache so the deployed changes are immediately visible.

**Prerequisites**: The site must be activated and the project root must be known (from Phase 4.1).

> 🚦 **Gate (plan · deploy-site:5.6.restart-cache):** Restart the deployed site to flush its runtime cache. Brief production downtime (a few seconds) — explicit user consent required even though the action is recoverable.
>
> **Trigger:** Site confirmed activated (either pre-existing or just activated in 5.5.1).
> **Why we ask:** Production users see stale content for several minutes until cache TTL expires.
> **Cancel leaves:** Nothing — the deploy itself already succeeded; cache will refresh on its own.

Use `AskUserQuestion` to confirm before proceeding:

| Question | Header | Options |
|----------|--------|---------|
| Would you like to restart the site so your latest changes are immediately visible? This may cause a brief downtime (a few seconds). | Restart | Yes, restart site (Recommended), Skip — I'll restart later |

**If "Skip"**: Skip to [Suggest Next Steps](#suggest-next-steps).

**If "Yes"**: Run the cache-clearing script, passing the project root:

```bash
node "${PLUGIN_ROOT}/scripts/clear-site-cache.js" --projectRoot ""
```

The script reads `siteName` from `powerpages.config.json`, looks up the website via the Power Platform API, and restarts it to flush the runtime cache.

Evaluate the result:

- **If `success` is `true`**: Inform the user: "Site cache cleared — your latest changes should now be visible at ****."
- **If `success` is `false`**: Warn the user that cache clearing failed and show the error, but do not block the deployment flow. The deployment itself succeeded; cache will eventually refresh on its own. Suggest the user can manually clear cache from the Power Pages admin center if needed.

**Output**: Deployment verified, changes committed, activation offered, cache cleared

---

## Phase 6: Handle Blocked JavaScript

**Goal**: Resolve blocked JavaScript attachment errors and retry deployment

**Actions**:

### 6.1 Explain the Issue

Tell the user:
> "The upload failed because JavaScript (.js) file attachments are blocked in your Power Pages environment. This is a security setting that prevents uploading .js files. To deploy a code site, this restriction needs to be relaxed for .js files."

### 6.2 Ask for Permission

> 🚦 **Gate (consent · deploy-site:6.2.unblock-js):** Reactive `blockedattachments` modification — destructive shared-state change (tenant-wide env setting). Same shape as `deploy-pipeline:7.6.2.blocked-attachments`.
>
> **Trigger:** Upload failed with the blocked-`.js` error.
> **Why we ask:** Auto-unblocking modifies a tenant security setting without explicit consent — visible across the entire environment, not just this site.
> **Cancel leaves:** `attachment-block-modified` is only possible if the user approved and then a downstream step partial-completed. Pure Cancel here leaves nothing — the original blockedattachments value is untouched.

Use `AskUserQuestion`:

| Question | Header | Options |
|----------|--------|---------|
| Would you like to remove the JavaScript (.js) block from the environment's blocked attachments list? This is required to deploy code sites. | Unblock JS | Yes, remove the .js block (Recommended), No, do not change environment settings |

**If "No"**: Stop and inform the user that the deployment cannot proceed without unblocking `.js` attachments.

**If "Yes"**: Proceed to 6.3.

### 6.3 Update Blocked Attachments

1. Run `pac env list-settings` to retrieve the current environment settings:

   ```bash
   pac env list-settings
   ```

2. Find the `blockedattachments` property in the output. It will contain a semicolon-separated list of file extensions (e.g., `ade;adp;app;asa;ashx;asmx;asp;bas;bat;cdx;cer;chm;class;cmd;com;config;cnt;cpl;crt;csh;der;dll;exe;fxp;hlp;hta;htr;htw;ida;idc;idq;inf;ins;isp;its;js;jse;ksh;lnk;mad;maf;mag;mam;maq;mar;mas;mat;mau;mav;maw;mda;mdb;mde;mdt;mdw;mdz;msc;msh;msh1;msh1xml;msh2;msh2xml;mshxml;msi;msp;mst;ops;pcd;pif;prf;prg;printer;pst;reg;rem;scf;scr;sct;shb;shs;shtm;shtml;soap;stm;tmp;url;vb;vbe;vbs;vsmacros;vss;vst;vsw;ws;wsc;wsf;wsh`).

3. Remove `js` from the list. Parse the semicolon-separated values, filter out `js`, and rejoin with semicolons.

4. Update the setting:

   ```bash
   pac env update-settings --name blockedattachments --value ""
   ```

5. Confirm the update was successful.

### 6.4 Retry Upload

Run the upload command again:

```

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [microsoft](https://github.com/microsoft)
- **Source:** [microsoft/power-platform-skills](https://github.com/microsoft/power-platform-skills)
- **License:** MIT
- **Homepage:** https://aka.ms/ppskills

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-microsoft-power-platform-skills-deploy-site
- Seller: https://agentstack.voostack.com/s/microsoft
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.