Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Activate Power Pages Site
Provision a new Power Pages website in a Power Platform environment via the Power Platform REST API.
Prerequisite: This skill expects an existing Power Pages code site created via
/create-site. Run that skill first if the site does not exist yet.
Core Principles
- Cloud-aware URL resolution — Never hardcode API base URLs or site URL domains. Always derive them from the Cloud value returned by
pac auth who. - Token handling — Scripts acquire and refresh Azure CLI tokens internally. The agent only needs to verify the user is logged in to Azure CLI.
- Confirm before mutating — Always present the full activation parameters to the user and get explicit approval before POSTing to the websites API.
Initial request: $ARGUMENTS
Workflow
- Phase 1: Verify Prerequisites — PAC CLI auth + Azure CLI login + activation status check
- Phase 2: Gather Parameters — Site name, subdomain, website record ID
- Phase 3: Confirm — Present all parameters to user for approval
- Phase 4: Activate & Poll — Run activation script (POST + poll provisioning status)
- Phase 5: Present Summary — Show site URL, suggest next steps
Phase 1: Verify Prerequisites
Goal: Ensure PAC CLI is installed and authenticated, and verify the user is logged in to Azure CLI (scripts handle token acquisition internally).
Actions
1.1 Verify PAC CLI
Run pac help to check if the PAC CLI is installed and available on the system PATH.
pac help
If the command fails (command not found / not recognized):
-
Tell the user: "PAC CLI is not installed. You can install it by running:"
dotnet tool install --global Microsoft.PowerApps.CLI.Tool -
If
dotnetis also not available, direct the user to https://aka.ms/PowerPlatformCLI for full installation instructions. -
After installation, verify by running
pac helpagain.
1.2 Check Authentication
Run pac auth who to check current authentication status.
pac auth who
If authenticated: Extract these values from the output:
- Environment ID — the GUID after
Environment ID: - Organization ID — the GUID after
Organization ID:(this is the Dataverse org ID) - Cloud — the value after
Cloud:(e.g.,Public,UsGov,UsGovHigh,UsGovDod,China)
If not authenticated: Follow the same authentication flow as deploy-site — ask the user for their environment URL and run pac auth create --environment "<URL>".
1.3 Verify Azure CLI Login
Verify the user is logged in to Azure CLI (the activation scripts acquire tokens internally):
az account show
If az is not installed or not logged in: Instruct the user to install Azure CLI and run az login --allow-no-subscriptions (this form works whether or not the user has an Azure subscription — the activation flow only needs an AAD token).
1.4 Check If Already Activated
Before gathering parameters, check whether the site is already activated by running the shared activation status script:
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-activation-status.js" --projectRoot "<PROJECT_ROOT>"
Where <PROJECT_ROOT> is the directory containing powerpages.config.json or .powerpages-site folder.
Evaluate the JSON result:
- If
activatedistrue: Inform the user their site is already activated atwebsiteUrl. Suggest next steps (Phase 5.3) and stop — do NOT proceed to Phase 2. - If
activatedisfalse: Proceed to Phase 2. - If
erroris present: Proceed to Phase 2 (do not block the activation flow).
Output
- PAC CLI installed and authenticated
- Environment ID, Organization ID, and Cloud value extracted
- Azure CLI login confirmed
- Activation status checked (already activated → stop early, not activated → continue)
Phase 2: Gather Parameters
Goal: Determine the site name, generate or accept a subdomain, and look up the website record ID needed for the activation API call.
Actions
2.1 Read Site Name
Look for powerpages.config.json in the current directory or one level of subdirectories using Glob:
**/powerpages.config.json
Read the file and extract the siteName field. If not found, ask the user for the site name using AskUserQuestion.
2.2 Generate Subdomain Suggestion
CRITICAL — This step is MANDATORY. You MUST ask the user about the subdomain before proceeding. Do NOT skip this step or auto-select a subdomain without user input.
Run the subdomain generator script to create a random suggestion:
node "${CLAUDE_PLUGIN_ROOT}/skills/activate-site/scripts/generate-subdomain.js"
This outputs a string like site-a3f2b1. Resolve the correct site URL domain from the Cloud value obtained in Phase 1.2:
| Cloud | Site URL Domain |
|---|---|
Public | powerappsportals.com |
UsGov | powerappsportals.us |
UsGovHigh | high.powerappsportals.us |
UsGovDod | appsplatform.us |
China | powerappsportals.cn |
🚦 Gate (plan · activate-site:2.2.subdomain): Confirm or override the generated subdomain. Subdomain is part of the resulting site URL; Cancel exits before any provisioning call.
Present the generated subdomain to the user and ask them to accept or enter their own using AskUserQuestion:
| Question | Header | Options |
|---|---|---|
Your site subdomain will be: <suggestion> (full URL: https://<suggestion>.<siteUrlDomain>). Would you like to use this subdomain or enter your own? | Subdomain | Use <suggestion> (Recommended), Enter a custom subdomain |
If custom: The user provides their own subdomain via "Other" free text input. Validate it is lowercase, alphanumeric with hyphens only, and 3-50 characters.
2.3 Get Website Record ID
Run pac pages list to get the website record ID:
pac pages list
Parse the output to find the website record that matches the site name. Extract the Website Record ID (GUID). If pac pages list returns no results or the command is not available, set websiteRecordId to $null — the API will create a new website record.
Output
- Site name determined (from config file or user input)
- Subdomain chosen (generated or custom)
- Website record ID resolved (GUID or null)
Phase 3: Confirm
Goal: Present all activation parameters to the user and get explicit approval before making the API call.
Actions
<!-- gate: activate-site:3.confirm | category=final | cancel-leaves=nothing -->🚦 Gate (final · activate-site:3.confirm): Last-call before the activation API call. All activation parameters echoed back; Cancel exits cleanly before provisioning. Fires fresh on every skill invocation. When
plan-almorchestrates multi-stage activation (Staging + Production), it invokesactivate-siteonce per stage — each invocation hits this gate fresh with its ownsiteName,subdomain, and target env. The Staging activation consent does NOT cover Production. Each stage's site URL is a separate go-live decision (different audiences, different timing).
Present all activation parameters to the user using AskUserQuestion:
| Question | Header | Options |
|---|---|---|
Ready to activate your Power Pages site with these settings:\n\n- Site name: <siteName>\n- Subdomain: <subdomain>.powerappsportals.com\n- Environment ID: <environmentId>\n\nProceed with activation? | Activate | Yes, activate the site (Recommended), No, cancel |
If "No": Stop the skill and inform the user they can re-run it later.
If "Yes": Proceed to Phase 4.
Output
- User has explicitly approved the activation pa