---

name: edit-site description: >- Plans, coordinates and customizes PAC CLI-downloaded Standard or Enhanced data model non-SPA Power Pages sites created from Microsoft templates or manually in Design Studio. Use for requests involving pages, localized content, navigation, assets, snippets, site markers, Liquid/web templates, page layouts, or styling. Coordinated work produces an approved browser-viewable plan, executes changes in dependency order, verifies the local result, and optionally hands off to deployment. Not for React, Angular, Vue, or Astro SPA sites. user-invocable: true allowed-tools: Read, Write, Edit, Grep, Glob, Bash, WebSearch, AskUserQuestion, Skill, TaskCreate, TaskUpdate, TaskList, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_search, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_fetch, mcp__plugin_power-pages_playwright__browser_navigate, mcp__plugin_power-pages_playwright__browser_evaluate, mcp__plugin_power-pages_playwright__browser_run_code_unsafe model: opus

Plugin check: Run node "${PLUGIN_ROOT}/scripts/check-version.js" — if it outputs a message, show it to the user before proceeding. For styling-only requests, reuse the result once per installed plugin version in the current conversation.

Customize a Non-SPA Power Pages Site

Coordinate local customization using the component authoring references. Do not duplicate their PAC metadata, identity, serialization, or validation rules.

Initial request: $ARGUMENTS

Preview disclosure

Read ${PLUGIN_ROOT}/references/non-spa-preview.md and apply its Entry and handoff protocol. Unless the initial request contains the explicit marker from an actual covered-skill handoff, present the Customization notice before site discovery, task creation, or any other project inspection. This notice is informational and does not replace plan or deployment approval. Include previewNoticeShown: true and invocationSource: edit-site in every covered child-skill request.

Read:

• ${PLUGIN_ROOT}/references/design-studio-site-discovery.md
• ${PLUGIN_ROOT}/skills/edit-site/references/non-spa-site-authoring.md

Apply Request routing before creating coordination tasks or starting the phases below. For styling-only requests outside a current approved coordinated execution, follow ${PLUGIN_ROOT}/skills/edit-site/references/style-site-workflow.md and finish after its local verification/report, without the phases below. For an individual page or component request, follow the shared authoring reference and finish after its verification/report. For coordinated work, also read:

• ${PLUGIN_ROOT}/references/site-design-quality.md
• ${PLUGIN_ROOT}/skills/edit-site/references/customization-plan-contract.md
• ${PLUGIN_ROOT}/skills/edit-site/references/content-and-page-compositions.md
• ${PLUGIN_ROOT}/skills/edit-site/references/visual-asset-planning.md

For coordinated new-site design or requested styling, also read:

• ${PLUGIN_ROOT}/skills/edit-site/references/styling/design-quality.md

Ownership

For coordinated work, this skill owns:

• selecting one downloaded non-SPA site;
• understanding the complete customization intent;
• resolving cross-operation dependencies;
• generating and obtaining approval for one customization plan;
• executing component workflows in dependency order;
• independently checking the combined local result;
• committing coherent customization units;
• offering deployment after local verification.

It authors webpage, snippet, web-file, web-template, page-template, and site-marker records only through ${PLUGIN_ROOT}/skills/edit-site/references/non-spa-site-authoring.md and the selected component reference. The author-webpage-content skill owns localized body HTML; the style-site reference workflow owns guarded styling. It does not upload, activate, or modify Dataverse directly. No dev server, live preview, or generated styling mockup is required. The HTML below is an approval document, not a rendering of the site; local checks cannot prove Studio/runtime appearance.

Progress tracking

For coordinated work, create these tasks before starting:

| Task subject | Active form | Description | |---|---|---| | Discover non-SPA site | Discovering non-SPA site | Select and validate one PAC-downloaded non-SPA site | | Gather customization intent | Gathering customization intent | Resolve pages, content, assets, languages, preservation, and visual direction | | Prepare customization plan | Preparing customization plan | Build persistent JSON and browser-viewable HTML plan artifacts | | Approve customization plan | Reviewing customization plan | Review and approve the complete coordinated local plan | | Execute customization | Customizing non-SPA site | Author components, compose content, and apply styling in dependency order | | Verify customization | Verifying customization | Validate component results, combined references, diff, and Git state | | Complete customization | Completing customization | Commit coherent changes, report local/live state, and offer deployment |

Phase 1: Discover and validate the site

1. Follow the shared non-SPA discovery contract. Accept a site root that is the current directory or a nested directory such as .powerpages-site/.
2. Require .portalconfig/, non-empty website.yml, and at least one non-SPA component directory. Reject powerpages.config.json-only SPA sites.
3. If several valid sites remain and request/workspace evidence does not identify one, ask the user to choose. Never select the first filesystem result.
4. Read the site identity, configured languages, existing pages, navigation, snippets, site markers and their page bindings, web files, web templates, page templates, CSS sources, Bootstrap evidence, logos, favicons, existing page imagery, and the exact callers of site-wide brand assets. For header work, resolve the active website header binding, its source/includes, localized branding snippets, navigation callers, and responsive/authenticated variants. Do not assume that a template named Header is the one the site uses. For a creationIntent: "new-site" handoff, revalidate verifiedBootstrapMajor against actual downloaded asset evidence with the create-site validator's --bootstrapVersion option. Never infer Bootstrap from a template name or silently migrate an existing site.
5. Treat missing component directories as readiness findings. Do not create directories merely to make a planned operation appear supported.
6. Establish the local comparison baseline before creating plan artifacts:
   • when no Git repository exists, initialize one at the narrowest project root containing the selected site and commit only the verified downloaded baseline as Initial non-SPA site baseline;
   • when Git exists, record the starting commit and pre-existing dirty paths;
   • never absorb unrelated or pre-existing dirty files into customization commits.
7. Define <PROJECT_ROOT> as the repository root that owns the selected site. For the normal nested layout it is the parent of .powerpages-site/; for a direct-root download it is that site root itself.
8. If docs/edit-site/current-plan.json or docs/edit-site/current-execution.json exists, validate the pair against the selected website identity. Offer to resume the first ready pending operation when its request still matches the user's intent; otherwise prepare a new plan.

Request routing

Use the smallest route that fully satisfies the request:

• styling-only work outside a current approved coordinated execution: follow ${PLUGIN_ROOT}/skills/edit-site/references/style-site-workflow.md, including its conditional scope and exact-diff/hash approvals, then report locally. Do not create coordination tasks, a broad plan, Git baseline, commits or deployment prompts;
• one narrow component change: execute the corresponding reference workflow through ${PLUGIN_ROOT}/skills/edit-site/references/non-spa-site-authoring.md;
• one straightforward page: use the lightweight webpage-reference workflow with one resolved author-webpage-content composition;
• multiple pages or cross-component dependencies: use the complete orchestration below;
• explicit new-site design handoff: use the complete orchestration, even for a one-page site, so visual direction, image delivery, structure, and final styling remain coordinated;
• an unambiguous continuation of creating a new site: use that same new-site route even if the caller omitted the literal creationIntent field. Establish it from the request/session intent, not a file timestamp or the mere presence of template metadata;
• a current approved execution to resume or additional approval needed by a component operation: use the complete orchestration and its existing gates before writing;
• SPA/code site: stop and explain that this skill is non-SPA-only.

Do not generate a broad plan or execute every owner merely because they are available.

Phase 2: Gather customization intent

Use the initial request and the template's data-model/domain and requirements context before asking questions. Template selection is not a visual specification. Do not ask again for information already established.

For a broad or underspecified request, collect:

• existing pages to preserve or modify;
• new pages, routes, parent relationships, and requested navigation;
• visitor-facing content and languages;
• assets, reusable snippets, Liquid templates, and custom layouts;
• required capabilities/content and any explicit user preservation preferences; for existing-site work, resolve preservation versus redesign only when the requested scope is unclear;
• aesthetic and mood for new-site design or requested visual customization.

For creationIntent: "new-site", the selected creation template is a data/domain and requirements reference, not a constraint on appearance, page composition, layout, branding, or presentation. Design the complete modern visitor experience from the user's intent, not the starter arrangement. Custom design and layout are required. Reuse needed native forms, lists, content snippets and their verified bindings as components; do not reuse the template's page composition by default. Remove or replace unneeded starter sections and component placements when the fresh composition calls for it. Template presence alone is not a preservation requirement; account for removals and their dependencies in the existing plan, without deleting backing records or unrelated callers. Honor explicit preservation preferences or a choice to keep the template unchanged; otherwise do not require separate redesign permission just to depart from it. Reuse the shared quality reference to choose a coherent typography system, role-based palette, spacing rhythm, responsive composition, and meaningful hero/supporting imagery. Make context-specific design decisions without asking for every font or color. Preserve required capabilities/content, valid PAC metadata, record identities and relationships, required forms/lists and data bindings, navigation, authentication, and locale scope. Native Bootstrap/Studio-compatible serialization is protected, not the template's section arrangement: plan supported recomposition through the native owners before final styling. Treat known section-layout recipes as defaults, not a pattern allowlist. Resolve explicit native column geometry even when the starter has no matching layout sample. Safe approved local layout changes with unobserved Studio editing behavior carry Studio editing compatibility unverified in the existing warnings/verification and report; do not add a live-check gate or silently downgrade the design. Known incompatibilities, unsafe source and unresolved scope remain blockers. Other element/owner contracts stay unchanged. Existing-site and narrow edits remain preservation-fir