$ loading_
Import Dataverse solution zips into target environments with staged validation.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "import-solution" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/power-platform-skills/main/plugins/power-pages/skills/import-solution/SKILL.md 2. Save it as ~/.claude/skills/import-solution/SKILL.md 3. Reload skills and tell me it's ready
Import this Dataverse solution zip into the test environment. Run a staged import first to check dependencies, then commit the installation if validation passes, and return a summary of the import result.
A dependency check result, import success status, and a summary of key logs or errors.
Deploy this solution package to the production environment. Validate before overwriting existing customizations; if dependencies are missing or conflicts exist, stop and report the issues.
Production deployment status, whether it was halted, key risks, and a list of issues that need attention.
Install the Dataverse solution for this site in a new environment. Check prerequisites first, complete the import, and tell me what post-install configuration steps are still needed.
The installation result, dependency validation findings, and a checklist of recommended post-install steps.
Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Imports a solution zip into a target Dataverse environment via ImportSolutionAsync. Supports optional staged import via StageSolution to check for missing dependencies before committing.
export-solution)
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:
<!-- gate: import-solution:0.no-plan | category=intent | cancel-leaves=nothing -->"No ALM plan exists for this project.
/power-pages:plan-almbuilds one — it detects the project state, asks about your promotion strategy (PP Pipelines vs Manual export/import), and orchestrates the right skills (including this one) in the right order. Want me to run plan-alm now?"
🚦 Gate (intent · import-solution:0.no-plan): Fail-closed entry gate when
check-alm-plan.jsreturnsexists:false. Helper-script-backed.
AskUserQuestion:
| Question | Header | Options |
|---|---|---|
Run /power-pages:plan-alm first? | ALM plan gate | Yes — run /power-pages:plan-alm now (Recommended), Continue without a plan (advanced — I know what I'm doing), Cancel |
/power-pages:plan-alm. plan-alm's Phase 7 dispatches back into this skill at the appropriate stage.…
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.
Add Azure DevOps to Power Apps for work items, bugs, pipelines, and API calls.
Set up Power Platform Pipelines for automated Power Pages deployments.
Create a publisher and solution, then package Power Pages components for ALM.
Create Dataverse tables, columns, and relationships from a proposed site data model.
Diagnose deployment failures, surface upload errors, and suggest or apply fixes.
Trigger and monitor Power Platform pipeline deployments for Power Pages solutions.
Integrate Power Pages Web API into frontend with permissions and deployment.
Configure Power Pages environment variables and deployment settings for multi-environment ALM.