$ loading_
Create a publisher and solution, then package Power Pages components for ALM.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "setup-solution" skill from askskill: 1. Download https://raw.githubusercontent.com/microsoft/power-platform-skills/main/plugins/power-pages/skills/setup-solution/SKILL.md 2. Save it as ~/.claude/skills/setup-solution/SKILL.md 3. Reload skills and tell me it's ready
Create a Dataverse publisher and solution for my Power Pages site, and add the site-related components so I can deploy it later.
Provides the created publisher and solution details and confirms the site components were added.
Add my existing Power Pages site components into a new solution for ALM and cross-environment deployment management.
Creates a solution suitable for application lifecycle management with the required site components included.
Set up the ALM foundation for this site: create a publisher, create a solution, and include all Power Pages components under solution management.
Delivers a fully solutionized setup ready for export, deployment, and environment migration.
Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Creates a Dataverse publisher and solution, then adds Power Pages site components. Writes .solution-manifest.json for use by export-solution, import-solution, and setup-pipeline skills.
pac env who returns an environment URL)az account show succeeds)powerpages.config.json exists in the project root (site must be deployed at least once so .powerpages-site/ exists with component records)
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, ... }. Sync mode (when .solution-manifest.json already exists) may additionally pass --envUrl, --token, --solutionId once Phase 1 has acquired them, but for the initial gate the existence-only check is sufficient.
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: setup-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 · setup-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 |
…
Run security scans on deployed Power Pages sites and summarize risks clearly.
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.
Integrate Power Automate cloud flows into Power Pages with generated metadata and code.
Configure Power Pages environment variables and deployment settings for multi-environment ALM.
Create and execute a reviewable ALM plan for Power Pages deployments.
Create Dataverse tables, columns, and relationships from a proposed site data model.
Create and launch a new Power Pages code site from concept to deployment.
Import Dataverse solution zips into target environments with staged validation.
Build and deploy an existing Power Pages code site to a target environment.