$ loading_
Trigger and monitor Power Platform pipeline deployments for Power Pages solutions.
The material indicates an open-source, prompt-oriented deployment skill with no declared built-in secrets or fixed remote endpoints, so overall risk is relatively low. However, it is designed to trigger real Power Platform deployments and relies on local config plus authenticated CLIs, so execution scope and completeness of the source should still be verified.
The material declares no environment variables or built-in secrets, but prerequisites require Azure CLI and PAC CLI to be logged in, meaning it may reuse existing local sessions and tokens. If run in a high-privilege tenant, there is a normal risk of deployment actions being performed via those existing credentials.
System checks indicate no fixed remote endpoint, but the skill’s purpose is to trigger a Power Platform Pipeline deployment and poll status, which would typically communicate with Microsoft services through authenticated Azure/PAC tools. No evidence is shown of exfiltration to unrelated third-party hosts.
The README explicitly includes running local Node scripts, version checks, gate helpers, and CLI actions such as `pac pipeline deploy`, which is standard local script/command execution. No extra system privileges unrelated to the deployment purpose are evident from the material.
The material shows it reads `docs/alm/last-pipeline.json`, `docs/.alm-plan-data.json`, `.solution-manifest.json`, and reference docs, and may handle deployment settings such as environment variables and connection references. The visible data-access scope appears mostly limited to project-local ALM/deployment files, with no clear sign of excessive access.
The source is an open-source Microsoft GitHub repository with auditable code, which materially lowers supply-chain risk. Although the license is unspecified, the repo has 0 stars, and maintenance status is unknown, those facts alone do not justify a high-risk rating.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "deploy-pipeline" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/power-platform-skills/main/plugins/power-pages/skills/deploy-pipeline/SKILL.md 2. Save it as ~/.claude/skills/deploy-pipeline/SKILL.md 3. Reload skills and tell me it's ready
Please run the Power Platform pipeline to deploy the Power Pages solution to the staging environment; validate the package first, then apply environment variable and connection reference settings, and keep polling until deployment completes.
Returns the triggered deployment job, target stage, validation result, configuration details, and the final success or failure status.
Push the current Power Pages solution to production through the pipeline using the specified deployment settings, and stop with the reason if validation fails.
Outputs the production release result, including validation status, whether deployment started, polling progress, and the final status.
Trigger a Power Platform pipeline deployment, configure environment variables and connection references for the target stage, then deploy and summarize the result after completion.
Provides confirmation that settings were applied, the deployment run record, and a final status summary with any error notices.
Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Triggers a Power Platform Pipeline deployment run. Reads the existing pipeline configuration from docs/alm/last-pipeline.json, selects a target stage, validates the solution package, and deploys it to the target environment.
Prerequisite: Run
/power-pages:setup-pipelinefirst to create the pipeline configuration.
Refer to
${CLAUDE_PLUGIN_ROOT}/references/cicd-pipeline-patterns.mdfor all HAR-confirmed API patterns used in this skill.
Important: The source (dev) environment must have a Power Platform Pipelines host environment configured. This is set in Power Platform Admin Center (Environments → select env → Pipelines) or via the tenant-level
DefaultCustomPipelinesHostEnvForTenantsetting. Without this configuration,pac pipeline deploywill fail. Thesetup-pipelineskill creates the pipeline definition in the host; this admin step connects the dev environment to that host.
docs/alm/last-pipeline.json exists (created by setup-pipeline).solution-manifest.json existsaz account show succeeds)pac env who succeeds)
plan-almis the front door. When the user expresses an ALM intent (promote / ship / deploy / move to staging / push to prod / release this version), the orchestrator (/power-pages:plan-alm) should run first. Direct invocation ofdeploy-pipelinebypasses the orchestrator's pre-plan completeness check, env-var resolution per stage, activation steps, and validation runs. This gate makes that bypass explicit.
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 "." \
--envUrl "{devEnvUrl}" \
--token "{token}" \
--solutionId "{solutionId from .solution-manifest.json, if available}"
The helper returns JSON with { exists, stale, staleness: { reason, detail }, generatedAt, planStatus, ... }. The freshness check requires env credentials + solutionId; without those the helper does an existence-only check.
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.
Build and deploy an existing Power Pages code site to a target environment.
Build and deploy a Power Apps code app to Power Platform.
Create and execute a reviewable ALM plan for Power Pages deployments.
Deploy prepared Azure apps with built-in recovery for common release errors.
Configure Power Pages environment variables and deployment settings for multi-environment ALM.
Create a publisher and solution, then package Power Pages components for ALM.