$ loading_
Configure Power Pages environment variables and deployment settings for multi-environment ALM.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "configure-env-variables" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/power-platform-skills/main/plugins/power-pages/skills/configure-env-variables/SKILL.md 2. Save it as ~/.claude/skills/configure-env-variables/SKILL.md 3. Reload skills and tell me it's ready
Please configure environment variables for my Power Pages site to separate site settings across dev, test, and production, and generate a deployment-settings.json file.
Creates environment variable definitions, explains how to link site settings in Power Pages Management, adds variables to the solution, and generates a deployment-settings.json with per-environment override values.
Help me convert existing Power Pages site settings into environment-specific configuration so different environments do not share the same hardcoded values.
Identifies site settings suitable for parameterization, creates matching environment variables, provides step-by-step linking guidance, and prepares environment override settings for deployment.
Please complete the deployment variable setup for this Power Pages solution, add the related environment variables to the solution, and output a deployment-settings.json for the release pipeline.
Produces an ALM-ready variable configuration plan, including Dataverse environment variable definitions, solution inclusion details, site setting mapping guidance, and a deployment configuration file.
Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Creates and links Dataverse environment variables to Power Pages site settings, enabling different configuration values per deployment environment (dev vs staging vs prod). Generates deployment-settings.json for use by deploy-pipeline.
Power Pages site settings can be backed by environment variables (GA March 2025, enhanced data model only). When linked:
mspp_source changes from 0 (static) to 1 (environment variable)mspp_valuedeploymentsettingsjsonAPI note: The site setting → env var link is set via a HAR-confirmed OData PATCH pattern (v9.0, EnvironmentValue nav property, if-match: * and clienthost: Browser headers required). This is handled by scripts/lib/link-site-setting-to-env-var.js. All steps are fully automated.
pac auth whoaz account get-access-token.solution-manifest.json exists in the project root (run setup-solution first).powerpages-site/ folder exists)
plan-almis the front door. When the user expresses an ALM intent (promote / ship / deploy / set up CI-CD / move to staging / push to prod), the orchestrator (/power-pages:plan-alm) should run first. This Phase 0 enforces that and is meant to fail closed when there's no plan, not to be a one-time check the user can dismiss forever.
Skip rule. If this skill was invoked as part of an active plan-alm orchestration, skip Phase 0 entirely and proceed to Phase 1. The gate helper exposes this via its inExecution block — pass through silently to Phase 1 when:
inExecution.status === "active"
The helper computes this from docs/.alm-plan-data.json — PLAN_STATUS === "In Execution" AND LAST_INVOCATION_AT within the last 60 minutes. check-alm-plan.js refreshes LAST_INVOCATION_AT automatically on every invocation that finds the plan in execution, so each in-chain skill keeps the chain alive for the next one — even multi-hour deploys (deploy-pipeline alone can take 60 min per stage) survive the window without the chain incorrectly de-classifying. Stalled chains (no heartbeat for > 60 min) reclassify as stale-heartbeat and Phase 0 gates fire normally so an abandoned plan doesn't silently bypass user confirmation.
When inExecution.status is anything other than "active" ("not-running", "stale-heartbeat", "no-plan"), run the Phase 0 gate flow below. Branch on the remaining helper fields:
Step 1 — Run the gate helper.
node "${CLAUDE_PLUGIN_ROOT}/scripts/lib/check-alm-plan.js" --projectRoot "."
The helper returns JSON with { exists, deferred, stale, staleness: { reason, detail }, generatedAt, planStatus, ... }. Pass --envUrl, --token, --solutionId once Phase 1 has acquired them if you also want a freshness check; otherwise the helper does an existence-only check, which is sufficient for the gate decision below.
Step 2 — Branch on the result.
| Result | Behavior |
|---|---|
deferred: true | The user has explicitly deferred ALM for this project (.alm-deferred marker present). Pass through silently to Phase 1 — do not nag. |
exists: false | The user hasn't run plan-alm yet. See Step 3. |
exists: true, stale: false | Plan is current. Pass through silently to Phase 1. |
exists: true, stale: true (reason: solution-modified) | The solution changed after the plan was generated. See Step 4. |
Step 3 — No plan. Tell the user:
…
Set up Power Platform Pipelines for automated Power Pages deployments.
Review and fix Power Pages security headers, CSP, CORS, cookies, and embedding settings.
Run an end-to-end Power Pages security review with a consolidated HTML report.
Test deployed Power Pages sites with browsing, crawling, and API verification.
Add a data source or connector to a Power Apps code app.
Integrate Power Automate cloud flows into Power Pages with generated metadata and code.
Create a publisher and solution, then package Power Pages components for ALM.
Create and execute a reviewable ALM plan for Power Pages deployments.
Build and deploy an existing Power Pages code site to a target environment.
Set up authentication, authorization, and identity providers for Power Pages sites.
Trigger and monitor Power Platform pipeline deployments for Power Pages solutions.
Activate and provision a Power Pages site in a Power Platform environment.