[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699TEPV0PBB5JCPZ1GZ1ZW2":3,"skill-same:01M699TEPV0PBB5JCPZ1GZ1ZW2":171},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":82},"01M699TEPV0PBB5JCPZ1GZ1ZW2","edit-site",null,"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\u002Fweb 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.","microsoft\u002Fpower-platform-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699JVYJFB75D9JM70BN4H0Q",1149,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,9,47,48,49,50,51],"edit","edit site","site","search","websearch","studio","markers","spa","local","power","fetch","model","Bash","angular","design","browser","code","learn","power pages","react","web","playwright","docs","cli","MCP","2026-11-10 10:12:30",false,"---\nname: edit-site\ndescription: >-\n  Plans, coordinates and customizes PAC CLI-downloaded Standard or Enhanced data model non-SPA\n  Power Pages sites created from Microsoft templates or manually in Design Studio. Use for\n  requests involving pages, localized content, navigation, assets, snippets, site markers,\n  Liquid\u002Fweb templates, page layouts, or styling. Coordinated work produces an approved\n  browser-viewable plan, executes changes in dependency order, verifies the local result,\n  and optionally hands off to deployment. Not for React, Angular, Vue, or Astro SPA sites.\nuser-invocable: true\nallowed-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\nmodel: opus\n---\n\n> **Plugin check**: Run `node \"${PLUGIN_ROOT}\u002Fscripts\u002Fcheck-version.js\"` — if it outputs a message, show it to the user before proceeding.\n> For styling-only requests, reuse the result once per installed plugin version in the current conversation.\n\n# Customize a Non-SPA Power Pages Site\n\nCoordinate local customization using the component authoring references.\nDo not duplicate their PAC metadata, identity, serialization, or validation rules.\n\n**Initial request:** $ARGUMENTS\n\n## Preview disclosure\n\nRead `${PLUGIN_ROOT}\u002Freferences\u002Fnon-spa-preview.md` and apply its **Entry and handoff\nprotocol**. Unless the initial request contains the explicit marker from an actual covered-skill\nhandoff, present the **Customization notice** before site discovery, task creation, or any other\nproject inspection. This notice is informational and does not replace plan or deployment\napproval. Include `previewNoticeShown: true` and\n`invocationSource: edit-site` in every covered child-skill request.\n\nRead:\n\n- `${PLUGIN_ROOT}\u002Freferences\u002Fdesign-studio-site-discovery.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md`\n\nApply **Request routing** before creating coordination tasks or starting the phases below.\nFor styling-only requests outside a current approved coordinated execution, follow\n`${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyle-site-workflow.md`\nand finish after its local verification\u002Freport, without the phases below.\nFor an individual page or component request, follow the shared authoring reference and\nfinish after its verification\u002Freport.\nFor coordinated work, also read:\n\n- `${PLUGIN_ROOT}\u002Freferences\u002Fsite-design-quality.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fcustomization-plan-contract.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fcontent-and-page-compositions.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fvisual-asset-planning.md`\n\nFor coordinated new-site design or requested styling, also read:\n\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-quality.md`\n\n## Ownership\n\nFor coordinated work, this skill owns:\n\n- selecting one downloaded non-SPA site;\n- understanding the complete customization intent;\n- resolving cross-operation dependencies;\n- generating and obtaining approval for one customization plan;\n- executing component workflows in dependency order;\n- independently checking the combined local result;\n- committing coherent customization units;\n- offering deployment after local verification.\n\nIt authors webpage, snippet, web-file, web-template, page-template, and site-marker records only through\n`${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md` and the selected component reference.\nThe `author-webpage-content` skill owns localized body HTML; the\n`style-site` reference workflow owns guarded styling.\nIt does not upload, activate, or modify Dataverse directly.\nNo dev server, live preview, or generated styling mockup is required. The HTML below is an\napproval document, not a rendering of the site; local checks cannot prove Studio\u002Fruntime appearance.\n\n## Progress tracking\n\nFor coordinated work, create these tasks before starting:\n\n| Task subject | Active form | Description |\n|---|---|---|\n| Discover non-SPA site | Discovering non-SPA site | Select and validate one PAC-downloaded non-SPA site |\n| Gather customization intent | Gathering customization intent | Resolve pages, content, assets, languages, preservation, and visual direction |\n| Prepare customization plan | Preparing customization plan | Build persistent JSON and browser-viewable HTML plan artifacts |\n| Approve customization plan | Reviewing customization plan | Review and approve the complete coordinated local plan |\n| Execute customization | Customizing non-SPA site | Author components, compose content, and apply styling in dependency order |\n| Verify customization | Verifying customization | Validate component results, combined references, diff, and Git state |\n| Complete customization | Completing customization | Commit coherent changes, report local\u002Flive state, and offer deployment |\n\n## Phase 1: Discover and validate the site\n\n1. Follow the shared non-SPA discovery contract. Accept a site root that is the current\n   directory or a nested directory such as `.powerpages-site\u002F`.\n2. Require `.portalconfig\u002F`, non-empty `website.yml`, and at least one non-SPA component\n   directory. Reject `powerpages.config.json`-only SPA sites.\n3. If several valid sites remain and request\u002Fworkspace evidence does not identify one, ask the\n   user to choose. Never select the first filesystem result.\n4. Read the site identity, configured languages, existing pages, navigation,\n   snippets, site markers and their page bindings, web files, web templates, page templates,\n   CSS sources, Bootstrap evidence, logos, favicons, existing page imagery, and the exact callers\n   of site-wide brand assets.\n   For header work, resolve the active website header binding, its source\u002Fincludes, localized\n   branding snippets, navigation callers, and responsive\u002Fauthenticated variants. Do not assume\n   that a template named `Header` is the one the site uses.\n   For a `creationIntent: \"new-site\"` handoff, revalidate `verifiedBootstrapMajor` against actual\n   downloaded asset evidence with the create-site validator's `--bootstrapVersion` option.\n   Never infer Bootstrap from a template name or silently migrate an existing site.\n5. Treat missing component directories as readiness findings. Do not create directories merely\n   to make a planned operation appear supported.\n6. Establish the local comparison baseline before creating plan artifacts:\n   - when no Git repository exists, initialize one at the narrowest project root containing the\n     selected site and commit only the verified downloaded baseline as\n     `Initial non-SPA site baseline`;\n   - when Git exists, record the starting commit and pre-existing dirty paths;\n   - never absorb unrelated or pre-existing dirty files into customization commits.\n7. Define `\u003CPROJECT_ROOT>` as the repository root that owns the selected site. For the normal\n   nested layout it is the parent of `.powerpages-site\u002F`; for a direct-root download it is that\n   site root itself.\n8. If `docs\u002Fedit-site\u002Fcurrent-plan.json` or\n   `docs\u002Fedit-site\u002Fcurrent-execution.json` exists, validate the pair against the\n   selected website identity. Offer to resume the first ready pending operation when its request\n   still matches the user's intent; otherwise prepare a new plan.\n\n## Request routing\n\nUse the smallest route that fully satisfies the request:\n\n- styling-only work outside a current approved coordinated execution: follow\n  `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyle-site-workflow.md`,\n  including its conditional scope and exact-diff\u002Fhash approvals, then report locally.\n  Do not create coordination tasks, a broad plan, Git baseline, commits or deployment prompts;\n- one narrow component change: execute the corresponding reference workflow through\n  `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md`;\n- one straightforward page: use the lightweight webpage-reference workflow with one resolved\n  `author-webpage-content` composition;\n- multiple pages or cross-component dependencies: use the complete orchestration below;\n- explicit new-site design handoff: use the complete orchestration, even for a one-page site,\n  so visual direction, image delivery, structure, and final styling remain coordinated;\n- an unambiguous continuation of creating a new site: use that same new-site route even if the\n  caller omitted the literal `creationIntent` field. Establish it from the request\u002Fsession intent,\n  not a file timestamp or the mere presence of template metadata;\n- a current approved execution to resume or additional approval needed by a component operation:\n  use the complete orchestration and its existing gates before writing;\n- SPA\u002Fcode site: stop and explain that this skill is non-SPA-only.\n\nDo not generate a broad plan or execute every owner merely because they are available.\n\n## Phase 2: Gather customization intent\n\nUse the initial request and the template's data-model\u002Fdomain and requirements context before\nasking questions. Template selection is not a visual specification. Do not ask again for\ninformation already established.\n\nFor a broad or underspecified request, collect:\n\n- existing pages to preserve or modify;\n- new pages, routes, parent relationships, and requested navigation;\n- visitor-facing content and languages;\n- assets, reusable snippets, Liquid templates, and custom layouts;\n- required capabilities\u002Fcontent and any explicit user preservation preferences; for existing-site\n  work, resolve preservation versus redesign only when the requested scope is unclear;\n- aesthetic and mood for new-site design or requested visual customization.\n\nFor `creationIntent: \"new-site\"`, the selected creation template is a data\u002Fdomain and requirements\nreference, not a constraint on appearance, page composition, layout, branding, or presentation.\nDesign the complete modern visitor experience from the user's intent, not the starter arrangement.\nCustom design and layout are required. Reuse needed native forms, lists, content snippets and\ntheir verified bindings as components; do not reuse the template's page composition by default.\nRemove or replace unneeded starter sections and component placements when the fresh composition\ncalls for it. Template presence alone is not a preservation requirement; account for removals\nand their dependencies in the existing plan, without deleting backing records or unrelated callers.\nHonor explicit preservation preferences or a choice to keep the template unchanged; otherwise\ndo not require separate redesign permission just to depart from it. Reuse the shared quality\nreference to choose a coherent typography system, role-based palette, spacing rhythm, responsive composition, and\nmeaningful hero\u002Fsupporting imagery. Make context-specific design decisions without asking for\nevery font or color. Preserve required capabilities\u002Fcontent, valid PAC metadata, record identities\nand relationships, required forms\u002Flists and data bindings, navigation, authentication, and locale scope.\nNative Bootstrap\u002FStudio-compatible serialization is protected, not the template's section\narrangement: plan supported recomposition through the native owners before final styling.\nTreat known section-layout recipes as defaults, not a pattern allowlist. Resolve explicit\nnative column geometry even when the starter has no matching layout sample.\nSafe approved local layout changes with unobserved Studio editing behavior carry\n**Studio editing compatibility unverified** in the existing warnings\u002Fverification and report;\ndo not add a live-check gate or silently downgrade the design. Known incompatibilities,\nunsafe source and unresolved scope remain blockers. Other element\u002Fowner contracts stay unchanged.\nExisting-site and narrow edits remain preservation-first unless redesign is requested.\nUse the native content-composition adapter below to select relevant `page-blueprints.md` narrative\npatterns once for a new-site design or approved redesign, without adopting its SPA execution rules.\nDerive the shared experience brief from known intent: audience\u002Fjob, primary and secondary\naction, principal doubt, honest proof, design thesis, first-screen concept, and signature moment.\nRecord the concise purpose in `summary` and the brief\u002Fnarrative decisions in\n`newSiteDesign.composition`, with implementation decisions in its existing typography, palette,\nspacing, and responsive fields. For an existing-site redesign without `newSiteDesign`, use the\nexisting summary and approved operation inputs. Do not add mandatory schema fields, rewrite old\napproved plans, or restart this brief in every child skill.\nSet `newSiteDesign.imageDelivery: \"external-url\"` for every new-site creation handoff. Add images\nusing approved direct HTTPS URLs in native image components; do not download them, create image\nWeb Files, or schedule image-import operations. Suitable existing template images may remain.\n\nApply **New-site custom layout planning** in the content-and-page-compositions reference before\nchoosing operations: separate the reusable-component inventory from the proposed Home\u002Fprimary-journey\ncomposition. Put concrete section and reused-component placements in the existing operation\ninputs, not only a design aspiration in `newSiteDesign.composition`.\nInspect similar pages for\nrequirements, bindings and supported serialization, not a mandatory design to copy;\nderive a content outline and supported `section -> columns -> elements` structure, draft safe\nexplanatory copy, and identify only organization-specific facts that require confirmation.\nPlan the first screen and narrative beats before styling; choose task-first layouts for forms,\nlists, and self-service pages. Map blueprint ideas to supported native layouts and real available\ncapabilities, not invented component types, literal SPA grids, or fabricated live counts.\n\nApply the visual-asset reference whenever imagery, branding, icons, illustrations, patterns, or\nfonts could materially improve the requested design. Resolve delivery first: new-site image\nadditions use user-approved hosted image URLs or curated Unsplash direct URLs. Existing-site file\nimports can still use user-provided files, original safe SVGs, and staged photography. Do not add an\nasset merely to fill space. Do not generate raster images or use another stock provider.\nFor a new-site design, include at least one relevant content photograph or original illustration\nwith an actual page placement; a logo, favicon, icon, or decorative divider alone is insufficient.\nAn explicit user choice to omit imagery is the only exception, recorded in `newSiteDesign`.\n\nFor new-site design and full-site redesign, explicitly plan the site header alongside the page\ncomposition; do not leave it at the starter appearance by omission. Follow **Site header planning**\nin `references\u002Fcontent-and-page-compositions.md`, reusing known brand and navigation decisions.\nFor every header update, explicitly resolve the logo or wordmark against the website requirements:\nupdate an unsuitable starter logo, or record justified retention. Header CSS alone does not\ncomplete an approved logo replacement. Follow **Logos and favicons** in the visual-asset reference\nfor source selection and missing brand inputs, without a separate approval gate.\nRecord concrete header treatment or a reasoned preservation decision in the existing plan, with\nnative owner operations for actual changes. A narrow existing-site edit does not expand to the\nheader unless requested. Header changes alone do not fulfill a new site's custom-layout brief.\n\n\u003C!-- not-a-gate: compact clarification gathers missing content and layout inputs; Phase 4 approves the plan -->\n\nWhen material inputs remain, ask once with the unresolved business facts plus compact choices for\ncontent source, navigation placement, locales, any unresolved preservation or styling scope,\nand only the unresolved asset decisions: approved brand files, permission\nto use Unsplash photography, and preserve\u002Fsupply\u002Fpropose\u002Fno-change logo direction. Prefer\nsite-derived defaults and do not repeat known information.\n\nGenerate context-aware feature choices from the selected template and current site. Do not offer\na capability whose required local structure is absent without presenting the missing prerequisite\nand remediation. Do not promise non-SPA form\u002Flist or data-model authoring unless a verified\nowning skill supports the requested operation. When the missing prerequisite is a basic form,\nlist, multistep form (advanced form\u002Fstep), or its backing Dataverse table\u002Fview\u002Ftable-permission,\nnever offer, as a selectable choice, to run PAC\u002FDataverse commands, create Dataverse tables, or\notherwise construct that record or its backing table locally — this skill and every skill it\ninvokes does not upload, activate, or modify Dataverse, and creating prerequisite tables is\nmodifying Dataverse.\n\n## Phase 3: Resolve and prepare the plan\n\n1. Resolve stable existing identities before planning: exact paths, IDs, routes, locale records,\n   template bindings, image URLs, applicable asset hashes\u002Fprovenance, and caller relationships.\n   For `delivery: \"external-url\"`, record the final HTTPS `externalUrl`, license basis, placements,\n   alt text and `preparation: { \"status\": \"remote\" }`. Put the exact URL in the consumer's static\n   inputs, with no Web File output binding. Review hosting\u002Fhotlink permission, privacy and known\n   CSP `img-src` restrictions; report unknown runtime behavior honestly, and never change CSP\n   implicitly. Do not call the staging helper for these images.\n   For Unsplash, follow the visual-asset reference's WebSearch-to-CDN flow, as in SPA creation.\n   Use a discovered direct image URL without requiring a photo-page fetch or photographer\n   lookup; retain those details when known, never invent them. Do not derive a CDN path from a\n   photo-page slug or search-result ID. A blocked photo page does not establish a CDN failure.\n   The renderer labels unchecked external images as unverified. Network source checks are\n   opt-in, not an additional prerequisite for the normal planning flow.\n   Only assets intentionally delivered as new Web Files are prepared through\n   `scripts\u002Fprepare-non-spa-asset.js`. Keep approved bytes in the project-local ignored asset\n   cache and record the returned hash, MIME type, dimensions, filename, and cache path. Do not\n   write staged bytes directly into the non-SPA site.\n2. Divide the request into the smallest coherent operations identified by:\n   `author-web-file`, `author-content-snippet`, `author-web-template`,\n   `author-page-template`, `author-webpage`, `author-site-marker`, `author-webpage-content`, and `style-site`.\n   Use the non-SPA authoring index's dispatch for component reference workflows.\n   Invoke only `author-webpage-content` through the `Skill` tool.\n   Execute `style-site` through its reference workflow.\n   New pages update navigation by default unless the user explicitly asks not to. Resolve\n   placement through the webpage reference and include it or the explicit opt-out in the\n   page operation's existing inputs and summary before approval.\n   For new-site design, map the proposed layout to actual native composition operations on Home\n   and the primary journey. Include web-template\u002Fpage-template or shared-shell work when that\n   source owns the layout; reusing a form\u002Flist\u002Fsnippet does not require retaining its whole page.\n   Include planned section\u002Fcomponent removals and their rationale in operation summaries and\n   resolved inputs; use supported native `replace` or scoped `modify` operations, not invented\n   deletion actions or CSS hiding. Retain required source\u002Fbindings and explicit exceptions in `preserve`.\n   A plan containing only copy\u002Fimage substitutions, additional pages and styling while leaving\n   the starter Home\u002Flayout intact is incomplete unless that scope was explicitly preserved.\n3. Order operations by actual dependencies, not by skill name. Assets\u002Fsnippets\u002Ftemplates normally\n   precede their consumers; webpage metadata must create an exact localized copy file before\n   `author-webpage-content` fills it; styling runs after structural authoring.\n   Include planned header snippet\u002Ftemplate changes in those dependencies before final styling.\n   CSS-only header treatment needs no dummy structural operation or website-binding change.\n4. Follow the plan contract and write a schema-version-1 JSON plan, including the complete\n   `assets` manifest and, for a new-site handoff, the complete `newSiteDesign` brief, into a fresh external review directory\n   outside the selected site root. Do not replace the canonical approved plan during review.\n\n   ```text\n   \u003CREVIEW_DIR>\u002Fplan.json\n   ```\n\n   Use the `\u003CPROJECT_ROOT>` resolved in Phase 1. Use a new review directory for every revision so\n   the renderer never overwrites reviewed bytes.\n   New-site styling operations must depend on all structural operations, directly or transitively.\n   Plan page\u002Fsection\u002Fsite placement through `style-site`; do not replace Bootstrap, `theme.css`,\n   or `portalbasictheme.css`, flatten native markup, or install a second CSS framework to achieve\n   SPA visual quality.\n5. Never write free-form unresolved values such as `TBD`, `heroImage`, `appropriate page`, or\n   `choose a snippet`. Use typed `outputBindings` for values produced by earlier operations;\n   otherwise resolve the value or stop with the exact missing input.\n6. Render the browser plan:\n\n   ```bash\n   node \"${PLUGIN_ROOT}\u002Fscripts\u002Frender-edit-site-plan.js\" \\\n     --output \"\u003CREVIEW_DIR>\u002Fplan.html\" \\\n     --data \"\u003CREVIEW_DIR>\u002Fplan.json\"\n   ```\n\n   If either review filename exists, create a fresh review directory instead of overwriting it.\n   By default, the renderer validates the plan without image-network requests or an image-check\n   report. It labels unchecked images unverified and returns their unique URL count as\n   `unverifiedImages`. Disclose that state in the approval summary; it does not block review.\n   Do not add a mandatory verification-choice question or live-preview requirement.\n\n   Only when the user requests source verification, append `--verifyImages true`. The verifier\n   checks each unique external URL once with bounded public-only HTTPS GETs and writes\n   `plan.html.image-checks.json` after all checks succeed. See the visual-asset reference for\n   limits and evidence semantics. If a check fails, do not request approval or silently disable\n   checks. Choose a working direct source URL, update every affected asset and consumer input,\n   and render a fresh review. Do not repeatedly retry a 404, silently drop required imagery, or\n   claim an unchecked URL is verified.\n7. Open the rendered HTML with the OS-native default-browser launcher. A launch failure does not\n   invalidate the plan; print the exact path as a fallback.\n\n## Phase 4: Approve the plan\n\nPresent a short terminal summary and direct the user to the HTML for the complete user-facing\nproposal: header treatment when in scope, pages and navigation, content and page compositions,\nassets and reusable components,\nstyling, preservation decisions, warnings, verification, and the local\u002Flive boundary. The HTML\ndescribes visible outcomes rather than authoring-skill mechanics. Do not include an inline\ntechnical implementation trace. Keep the complete execution details in the validated JSON,\nwhich remains the execution source of truth and is persisted after approval.\n\n\u003C!-- gate: edit-site:4.approve | category=plan | cancel-leaves=plan-artifacts -->\n\n> ? **Gate (plan · edit-site:4.approve):** Approve the coordinated\n> customization plan before executing any authoring operation.\n>\n> **Trigger:** JSON and HTML plan artifacts are complete, with external images explicitly\n> unverified or supported by successful requested checks for this exact plan.\n> **Why:** The next phase can create or modify several related non-SPA records.\n> **Cancel leaves:** External review artifacts only; the downloaded site and current approved plan\n> remain unchanged.\n\nUse `AskUserQuestion`:\n\n| Question | Header | Options |\n|---|---|---|\n| Does this non-SPA site customization plan look good? | Customization plan | Approve and customize, Revise plan, Cancel |\n\nOn revision, create a fresh review directory, render and open it, and repeat approval. Never edit\nthe rendered HTML as the source of truth.\n\nAfter approval, publish the approved JSON:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpromote-edit-site-plan.js\" \\\n  --projectRoot \"\u003CPROJECT_ROOT>\" \\\n  --data \"\u003CAPPROVED_REVIEW_DIR>\u002Fplan.json\"\n```\n\nIf the approved review included source checks, append\n`--imageChecks \"\u003CAPPROVED_REVIEW_DIR>\u002Fplan.html.image-checks.json\"`; otherwise omit it.\n\nThe publisher validates the approved JSON, renders canonical HTML from that exact data, creates\n`current-execution.json`, and records hashes plus a run ID. When a current approved run exists, it\narchives the plan, HTML, execution receipt, and icon together before replacement. Use only the\npublished current plan and execution receipt for authoring coordination.\nThe publisher makes no image-network requests. Unchecked images remain explicitly unverified\nin the canonical HTML and command result. A supplied report must match the exact plan and contain\nsuccessful checks; it is copied into the execution receipt. Missing, malformed, stale or failed\nsupplied reports block publication, never silently downgrade it. Preserve the reviewed evidence\nstate; do not drop a checked review's report or invent one for unchecked images. Changed plans\nneed fresh review and approval, and fresh checks if requested.\n\n## Phase 5: Execute through owning workflows\n\nFor each ready operation:\n\n1. Run the execution helper with `--action resolve`; it blocks until dependencies are complete and\n   returns the operation plus effective `resolvedInputs` combining approved static inputs with\n   actual bound outputs.\n2. Mark the operation `start`, then use the non-SPA authoring index to dispatch that resolved\n   operation. Execute reference workflows directly; invoke only\n   `author-webpage-content` as a skill. Supply the approved `designContext` when\n   returned. Carry its new-site composition and explicit preservation\n   decisions, not an implicit instruction to retain the creation template's layout or branding.\n   The shared brief supplies Bootstrap and visual direction, not permission to change unrelated\n   records, discard required capabilities\u002Fcontent, or bypass the owner's approval.\n   If returned, also pass `imageChecks`: reuse these source checks for unchanged URLs instead of\n   probing once per child or placement. Keep local caller\u002FURL verification and browser failure\n   handling. Previously approved receipts without this optional field remain resumable, but do\n   not claim their image sources were checked. An unchecked new plan has the same resumable\n   behavior. A source change needs a new approved plan, with fresh checks if requested.\n3. Retain the exact selected site root, action, target identity, locales, final values, callers,\n   and preservation requirements. For a covered-skill handoff, include\n   `previewNoticeShown: true` and `invocationSource: edit-site`.\n   The operation may be expressed as structured\n   YAML\u002FJSON or unambiguous natural language; it must resolve the same decisions as the plan\n   contract.\n4. Revalidate every supplied path and existing ID before writing; require\n   the same check in child-skill handoffs.\n5. After completion, re-read the changed files, write actual stable outputs to a temporary JSON\n   object, and mark the operation `complete --outputs \u003Cpath>`. Remove that temporary file after the\n   receipt is updated.\n6. On failure, mark the operation `fail` with the concise error and stop. Do not silently adapt\n   dependent operations to an unapproved structural change. On a later session, inspect any\n   partial files before restarting that failed operation; never blindly replay it.\n7. After all operations complete, run the execution helper with `--action finish`.\n\nExecute the `author-webpage` reference workflow for page records, routes, parents, template\nassignment, localized shells, and navigation within the approved scope. Invoke `author-webpage-content` after\nthat workflow resolves the page handoff. Invoke it directly only when one exact existing localized target\nfile and its composition are already resolved.\nCarry the verified Bootstrap major through the page-owner handoff into section\u002Felement authoring.\nUse Bootstrap 5 serialization for the verified new-site default and the inspected site-local\nBootstrap 3 patterns only for the explicit compatibility path.\n\nFor every staged visual asset, execute the `author-web-file` reference workflow before its consumers and record the\nverified `publicUrl`. Dependent page, snippet, template, or styling operations must consume that\nURL through an approved `outputBindings` entry; never predict a Web File URL. For a global logo or\nfavicon, update only the exact verified snippet, template, or setting callers. Resolve all approved\ndesktop\u002Fmobile logo variants and requested locales, including the accessible brand name and\nhome-link destination; do not assume one logo snippet covers every header state. Do not replace the\nwhole header merely to change a logo, and preserve navigation, search, language selection,\nsign-in behavior, and authenticated\u002Fanonymous branches.\n\nFor external images, pass the exact approved HTTPS URL directly to the native content owner.\nFollow **External image** in the image-component reference; keep responsive sizing and localized\nalt text, and do not invent local filenames or Web File `name` attributes. External CSS image\nURLs also belong in `style-site`'s exact `externalResources` review. `style-site` does not fetch\nthem or replace the image component.\n\nFor styling, execute the `style-site` reference workflow last. Its exact-diff\u002Fhash approval is a separate binding between\nthe user-reviewed CSS proposal and the bytes applied; the customization-plan approval does not\nreplace that safety gate.\n\nDo not execute an empty operation, and do not invoke deployment from this phase.\n\n## Phase 6: Verify the combined result\n\n1. Require every component workflow's and child skill's own verification to succeed.\n2. Re-run non-SPA site discovery and confirm the selected root and website identity are\n   unchanged.\n3. Verify planned files and records exist, generated identities are unique, locale scope matches\n   the plan, dependencies resolve, and unrequested callers\u002Fcontent remain unchanged. For Web File assets,\n   verify the approved SHA-256, file\u002FYAML pair, MIME type, dimensions, public URL, localized alt\n   text, caller placement, and absence of unapproved SVG active content or Design Studio\n   placeholders.\n   For external images, verify the caller's decoded URL equals the approved `externalUrl`, alt\n   text and layout\u002Fcrop intent are present, and no image cache, binary, YAML or import operation\n   was introduced. The plan hashes the URL, not mutable remote bytes; availability and CSP remain\n   pending runtime checks unless separately performed.\n4. Review the complete Git diff against the approved plan. Unexpected component categories or\n   unrelated changes block completion. Classify `docs\u002Fedit-site\u002F**` separately as\n   orchestration evidence; it is not a PAC component category and is not uploaded.\n5. Run the create-site non-SPA validator when a website record ID is available:\n\n   ```bash\n   node \"${PLUGIN_ROOT}\u002Fskills\u002Fcreate-site\u002Fscripts\u002Fvalidate-site.js\" \\\n     --projectRoot \"\u003CPROJECT_ROOT>\" \\\n     --websiteRecordId \"\u003CWEBSITE_RECORD_ID>\"\n   ```\n\n   For `newSiteDesign`, append `--bootstrapVersion \"\u003CnewSiteDesign.bootstrapMajor>\"`.\n6. For a new-site design, compare the result with every approved brief decision and image\n   placement: approved image URLs and callers (or reused existing assets), meaningful localized alternative text, responsive\n   sizing\u002Fcrops, readable text on every intended surface, and consistent hierarchy\u002Fspacing.\n   Reuse `style-site`'s local contrast checks and resolve known failures. Report desktop\u002Fmobile\n   rendering, Studio save\u002Freopen, and unknown image-overlay contrast as pending separate live\n   checks; do not start a server or claim local validation proves visual fidelity.\n   For any planned header work, trace its branding, source and styling decisions to the changed\n   native files and retained navigation, authentication, locale and caching contracts. Confirm the\n   approved logo or wordmark in every resolved desktop\u002Fmobile caller and requested locale,\n   including its source\u002Fvalue, accessible name, link destination and responsive sizing intent.\n   An unchanged starter logo is incomplete when the plan approved its replacement. Report\n   missing planned header work as incomplete; mobile-menu, keyboard and live-state behavior\n   remain unverified until separately observed.\n7. Compare the completed composition with the approved experience brief once, using\n   `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-critique.md`'s native interpretation of the\n   shared categories and source-only evidence.\n   Trace the planned Home\u002Fprimary-journey section structure and reused-component placements to\n   the changed native files, including the source that actually owns the shell. Compare against\n   the downloaded baseline: copy\u002Fimage swaps or CSS on an unchanged starter layout do not satisfy\n   a custom-layout brief. Record missing planned composition work as incomplete and return it to\n   its native owner through the existing revision\u002Fapproval flow, not a completed modern design.\n   Verify that approved removals are absent from the authored source, not merely hidden by CSS,\n   and that required components, their dependencies and explicitly preserved regions remain intact.\n   A changed section count or new class name alone is not evidence of custom composition.\n   Reuse child verification and, when present, the approved image-check receipt; do not repeat unchanged network\n   probes, add a screenshot gate, or run a critique per operation. Report observed local gaps and\n   unobserved runtime checks separately, retaining unverified status for unchecked images.\n   Revisions still require the existing plan\u002Fowner approvals;\n   a low or provisional visual score does not authorize direct edits or deployment.\n\n## Phase 7: Commit, report, and offer deployment\n\nCommit coherent customization units rather than combining the untouched template baseline with\nnew work. Do not commit unrelated pre-existing changes.\n\nReport:\n\n- site identity and local root;\n- current approved plan, HTML, and execution paths, plus any archived predecessor;\n- created and modified components grouped by authoring operation;\n- languages and routes affected;\n- validation and commit results;\n- warnings and pending runtime checks;\n- explicit state: local customization is not live until deployment succeeds.\n\n\u003C!-- gate: edit-site:7.deploy | category=plan | cancel-leaves=local-customization -->\n\n> ? **Gate (plan · edit-site:7.deploy):** Choose whether to dispatch the\n> verified local non-SPA project to `\u002Fdeploy-site`.\n>\n> **Trigger:** Local customization and combined verification succeeded.\n> **Why:** Deployment has its own environment and final-upload consent gates.\n> **Cancel leaves:** Verified local customization and commits.\n\nAsk: **Deploy these non-SPA site changes now?** Options: **Deploy now**, **Keep changes\nlocal**. On deploy, invoke `\u002Fdeploy-site` with the exact project root. Otherwise finish with the\nlocal\u002Flive distinction.\n\nRecord normal successful usage as `EditSite` through\n`${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md`.\n","> **Plugin check**: Run `node \"${PLUGIN_ROOT}\u002Fscripts\u002Fcheck-version.js\"` — if it outputs a message, show it to the user before proceeding.\n> For styling-only requests, reuse the result once per installed plugin version in the current conversation.\n\n# Customize a Non-SPA Power Pages Site\n\nCoordinate local customization using the component authoring references.\nDo not duplicate their PAC metadata, identity, serialization, or validation rules.\n\n**Initial request:** $ARGUMENTS\n\n## Preview disclosure\n\nRead `${PLUGIN_ROOT}\u002Freferences\u002Fnon-spa-preview.md` and apply its **Entry and handoff\nprotocol**. Unless the initial request contains the explicit marker from an actual covered-skill\nhandoff, present the **Customization notice** before site discovery, task creation, or any other\nproject inspection. This notice is informational and does not replace plan or deployment\napproval. Include `previewNoticeShown: true` and\n`invocationSource: edit-site` in every covered child-skill request.\n\nRead:\n\n- `${PLUGIN_ROOT}\u002Freferences\u002Fdesign-studio-site-discovery.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md`\n\nApply **Request routing** before creating coordination tasks or starting the phases below.\nFor styling-only requests outside a current approved coordinated execution, follow\n`${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyle-site-workflow.md`\nand finish after its local verification\u002Freport, without the phases below.\nFor an individual page or component request, follow the shared authoring reference and\nfinish after its verification\u002Freport.\nFor coordinated work, also read:\n\n- `${PLUGIN_ROOT}\u002Freferences\u002Fsite-design-quality.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fcustomization-plan-contract.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fcontent-and-page-compositions.md`\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fvisual-asset-planning.md`\n\nFor coordinated new-site design or requested styling, also read:\n\n- `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-quality.md`\n\n## Ownership\n\nFor coordinated work, this skill owns:\n\n- selecting one downloaded non-SPA site;\n- understanding the complete customization intent;\n- resolving cross-operation dependencies;\n- generating and obtaining approval for one customization plan;\n- executing component workflows in dependency order;\n- independently checking the combined local result;\n- committing coherent customization units;\n- offering deployment after local verification.\n\nIt authors webpage, snippet, web-file, web-template, page-template, and site-marker records only through\n`${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md` and the selected component reference.\nThe `author-webpage-content` skill owns localized body HTML; the\n`style-site` reference workflow owns guarded styling.\nIt does not upload, activate, or modify Dataverse directly.\nNo dev server, live preview, or generated styling mockup is required. The HTML below is an\napproval document, not a rendering of the site; local checks cannot prove Studio\u002Fruntime appearance.\n\n## Progress tracking\n\nFor coordinated work, create these tasks before starting:\n\n| Task subject | Active form | Description |\n|---|---|---|\n| Discover non-SPA site | Discovering non-SPA site | Select and validate one PAC-downloaded non-SPA site |\n| Gather customization intent | Gathering customization intent | Resolve pages, content, assets, languages, preservation, and visual direction |\n| Prepare customization plan | Preparing customization plan | Build persistent JSON and browser-viewable HTML plan artifacts |\n| Approve customization plan | Reviewing customization plan | Review and approve the complete coordinated local plan |\n| Execute customization | Customizing non-SPA site | Author components, compose content, and apply styling in dependency order |\n| Verify customization | Verifying customization | Validate component results, combined references, diff, and Git state |\n| Complete customization | Completing customization | Commit coherent changes, report local\u002Flive state, and offer deployment |\n\n## Phase 1: Discover and validate the site\n\n1. Follow the shared non-SPA discovery contract. Accept a site root that is the current\n   directory or a nested directory such as `.powerpages-site\u002F`.\n2. Require `.portalconfig\u002F`, non-empty `website.yml`, and at least one non-SPA component\n   directory. Reject `powerpages.config.json`-only SPA sites.\n3. If several valid sites remain and request\u002Fworkspace evidence does not identify one, ask the\n   user to choose. Never select the first filesystem result.\n4. Read the site identity, configured languages, existing pages, navigation,\n   snippets, site markers and their page bindings, web files, web templates, page templates,\n   CSS sources, Bootstrap evidence, logos, favicons, existing page imagery, and the exact callers\n   of site-wide brand assets.\n   For header work, resolve the active website header binding, its source\u002Fincludes, localized\n   branding snippets, navigation callers, and responsive\u002Fauthenticated variants. Do not assume\n   that a template named `Header` is the one the site uses.\n   For a `creationIntent: \"new-site\"` handoff, revalidate `verifiedBootstrapMajor` against actual\n   downloaded asset evidence with the create-site validator's `--bootstrapVersion` option.\n   Never infer Bootstrap from a template name or silently migrate an existing site.\n5. Treat missing component directories as readiness findings. Do not create directories merely\n   to make a planned operation appear supported.\n6. Establish the local comparison baseline before creating plan artifacts:\n   - when no Git repository exists, initialize one at the narrowest project root containing the\n     selected site and commit only the verified downloaded baseline as\n     `Initial non-SPA site baseline`;\n   - when Git exists, record the starting commit and pre-existing dirty paths;\n   - never absorb unrelated or pre-existing dirty files into customization commits.\n7. Define `\u003CPROJECT_ROOT>` as the repository root that owns the selected site. For the normal\n   nested layout it is the parent of `.powerpages-site\u002F`; for a direct-root download it is that\n   site root itself.\n8. If `docs\u002Fedit-site\u002Fcurrent-plan.json` or\n   `docs\u002Fedit-site\u002Fcurrent-execution.json` exists, validate the pair against the\n   selected website identity. Offer to resume the first ready pending operation when its request\n   still matches the user's intent; otherwise prepare a new plan.\n\n## Request routing\n\nUse the smallest route that fully satisfies the request:\n\n- styling-only work outside a current approved coordinated execution: follow\n  `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyle-site-workflow.md`,\n  including its conditional scope and exact-diff\u002Fhash approvals, then report locally.\n  Do not create coordination tasks, a broad plan, Git baseline, commits or deployment prompts;\n- one narrow component change: execute the corresponding reference workflow through\n  `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md`;\n- one straightforward page: use the lightweight webpage-reference workflow with one resolved\n  `author-webpage-content` composition;\n- multiple pages or cross-component dependencies: use the complete orchestration below;\n- explicit new-site design handoff: use the complete orchestration, even for a one-page site,\n  so visual direction, image delivery, structure, and final styling remain coordinated;\n- an unambiguous continuation of creating a new site: use that same new-site route even if the\n  caller omitted the literal `creationIntent` field. Establish it from the request\u002Fsession intent,\n  not a file timestamp or the mere presence of template metadata;\n- a current approved execution to resume or additional approval needed by a component operation:\n  use the complete orchestration and its existing gates before writing;\n- SPA\u002Fcode site: stop and explain that this skill is non-SPA-only.\n\nDo not generate a broad plan or execute every owner merely because they are available.\n\n## Phase 2: Gather customization intent\n\nUse the initial request and the template's data-model\u002Fdomain and requirements context before\nasking questions. Template selection is not a visual specification. Do not ask again for\ninformation already established.\n\nFor a broad or underspecified request, collect:\n\n- existing pages to preserve or modify;\n- new pages, routes, parent relationships, and requested navigation;\n- visitor-facing content and languages;\n- assets, reusable snippets, Liquid templates, and custom layouts;\n- required capabilities\u002Fcontent and any explicit user preservation preferences; for existing-site\n  work, resolve preservation versus redesign only when the requested scope is unclear;\n- aesthetic and mood for new-site design or requested visual customization.\n\nFor `creationIntent: \"new-site\"`, the selected creation template is a data\u002Fdomain and requirements\nreference, not a constraint on appearance, page composition, layout, branding, or presentation.\nDesign the complete modern visitor experience from the user's intent, not the starter arrangement.\nCustom design and layout are required. Reuse needed native forms, lists, content snippets and\ntheir verified bindings as components; do not reuse the template's page composition by default.\nRemove or replace unneeded starter sections and component placements when the fresh composition\ncalls for it. Template presence alone is not a preservation requirement; account for removals\nand their dependencies in the existing plan, without deleting backing records or unrelated callers.\nHonor explicit preservation preferences or a choice to keep the template unchanged; otherwise\ndo not require separate redesign permission just to depart from it. Reuse the shared quality\nreference to choose a coherent typography system, role-based palette, spacing rhythm, responsive composition, and\nmeaningful hero\u002Fsupporting imagery. Make context-specific design decisions without asking for\nevery font or color. Preserve required capabilities\u002Fcontent, valid PAC metadata, record identities\nand relationships, required forms\u002Flists and data bindings, navigation, authentication, and locale scope.\nNative Bootstrap\u002FStudio-compatible serialization is protected, not the template's section\narrangement: plan supported recomposition through the native owners before final styling.\nTreat known section-layout recipes as defaults, not a pattern allowlist. Resolve explicit\nnative column geometry even when the starter has no matching layout sample.\nSafe approved local layout changes with unobserved Studio editing behavior carry\n**Studio editing compatibility unverified** in the existing warnings\u002Fverification and report;\ndo not add a live-check gate or silently downgrade the design. Known incompatibilities,\nunsafe source and unresolved scope remain blockers. Other element\u002Fowner contracts stay unchanged.\nExisting-site and narrow edits remain preservation-first unless redesign is requested.\nUse the native content-composition adapter below to select relevant `page-blueprints.md` narrative\npatterns once for a new-site design or approved redesign, without adopting its SPA execution rules.\nDerive the shared experience brief from known intent: audience\u002Fjob, primary and secondary\naction, principal doubt, honest proof, design thesis, first-screen concept, and signature moment.\nRecord the concise purpose in `summary` and the brief\u002Fnarrative decisions in\n`newSiteDesign.composition`, with implementation decisions in its existing typography, palette,\nspacing, and responsive fields. For an existing-site redesign without `newSiteDesign`, use the\nexisting summary and approved operation inputs. Do not add mandatory schema fields, rewrite old\napproved plans, or restart this brief in every child skill.\nSet `newSiteDesign.imageDelivery: \"external-url\"` for every new-site creation handoff. Add images\nusing approved direct HTTPS URLs in native image components; do not download them, create image\nWeb Files, or schedule image-import operations. Suitable existing template images may remain.\n\nApply **New-site custom layout planning** in the content-and-page-compositions reference before\nchoosing operations: separate the reusable-component inventory from the proposed Home\u002Fprimary-journey\ncomposition. Put concrete section and reused-component placements in the existing operation\ninputs, not only a design aspiration in `newSiteDesign.composition`.\nInspect similar pages for\nrequirements, bindings and supported serialization, not a mandatory design to copy;\nderive a content outline and supported `section -> columns -> elements` structure, draft safe\nexplanatory copy, and identify only organization-specific facts that require confirmation.\nPlan the first screen and narrative beats before styling; choose task-first layouts for forms,\nlists, and self-service pages. Map blueprint ideas to supported native layouts and real available\ncapabilities, not invented component types, literal SPA grids, or fabricated live counts.\n\nApply the visual-asset reference whenever imagery, branding, icons, illustrations, patterns, or\nfonts could materially improve the requested design. Resolve delivery first: new-site image\nadditions use user-approved hosted image URLs or curated Unsplash direct URLs. Existing-site file\nimports can still use user-provided files, original safe SVGs, and staged photography. Do not add an\nasset merely to fill space. Do not generate raster images or use another stock provider.\nFor a new-site design, include at least one relevant content photograph or original illustration\nwith an actual page placement; a logo, favicon, icon, or decorative divider alone is insufficient.\nAn explicit user choice to omit imagery is the only exception, recorded in `newSiteDesign`.\n\nFor new-site design and full-site redesign, explicitly plan the site header alongside the page\ncomposition; do not leave it at the starter appearance by omission. Follow **Site header planning**\nin `references\u002Fcontent-and-page-compositions.md`, reusing known brand and navigation decisions.\nFor every header update, explicitly resolve the logo or wordmark against the website requirements:\nupdate an unsuitable starter logo, or record justified retention. Header CSS alone does not\ncomplete an approved logo replacement. Follow **Logos and favicons** in the visual-asset reference\nfor source selection and missing brand inputs, without a separate approval gate.\nRecord concrete header treatment or a reasoned preservation decision in the existing plan, with\nnative owner operations for actual changes. A narrow existing-site edit does not expand to the\nheader unless requested. Header changes alone do not fulfill a new site's custom-layout brief.\n\n\u003C!-- not-a-gate: compact clarification gathers missing content and layout inputs; Phase 4 approves the plan -->\n\nWhen material inputs remain, ask once with the unresolved business facts plus compact choices for\ncontent source, navigation placement, locales, any unresolved preservation or styling scope,\nand only the unresolved asset decisions: approved brand files, permission\nto use Unsplash photography, and preserve\u002Fsupply\u002Fpropose\u002Fno-change logo direction. Prefer\nsite-derived defaults and do not repeat known information.\n\nGenerate context-aware feature choices from the selected template and current site. Do not offer\na capability whose required local structure is absent without presenting the missing prerequisite\nand remediation. Do not promise non-SPA form\u002Flist or data-model authoring unless a verified\nowning skill supports the requested operation. When the missing prerequisite is a basic form,\nlist, multistep form (advanced form\u002Fstep), or its backing Dataverse table\u002Fview\u002Ftable-permission,\nnever offer, as a selectable choice, to run PAC\u002FDataverse commands, create Dataverse tables, or\notherwise construct that record or its backing table locally — this skill and every skill it\ninvokes does not upload, activate, or modify Dataverse, and creating prerequisite tables is\nmodifying Dataverse.\n\n## Phase 3: Resolve and prepare the plan\n\n1. Resolve stable existing identities before planning: exact paths, IDs, routes, locale records,\n   template bindings, image URLs, applicable asset hashes\u002Fprovenance, and caller relationships.\n   For `delivery: \"external-url\"`, record the final HTTPS `externalUrl`, license basis, placements,\n   alt text and `preparation: { \"status\": \"remote\" }`. Put the exact URL in the consumer's static\n   inputs, with no Web File output binding. Review hosting\u002Fhotlink permission, privacy and known\n   CSP `img-src` restrictions; report unknown runtime behavior honestly, and never change CSP\n   implicitly. Do not call the staging helper for these images.\n   For Unsplash, follow the visual-asset reference's WebSearch-to-CDN flow, as in SPA creation.\n   Use a discovered direct image URL without requiring a photo-page fetch or photographer\n   lookup; retain those details when known, never invent them. Do not derive a CDN path from a\n   photo-page slug or search-result ID. A blocked photo page does not establish a CDN failure.\n   The renderer labels unchecked external images as unverified. Network source checks are\n   opt-in, not an additional prerequisite for the normal planning flow.\n   Only assets intentionally delivered as new Web Files are prepared through\n   `scripts\u002Fprepare-non-spa-asset.js`. Keep approved bytes in the project-local ignored asset\n   cache and record the returned hash, MIME type, dimensions, filename, and cache path. Do not\n   write staged bytes directly into the non-SPA site.\n2. Divide the request into the smallest coherent operations identified by:\n   `author-web-file`, `author-content-snippet`, `author-web-template`,\n   `author-page-template`, `author-webpage`, `author-site-marker`, `author-webpage-content`, and `style-site`.\n   Use the non-SPA authoring index's dispatch for component reference workflows.\n   Invoke only `author-webpage-content` through the `Skill` tool.\n   Execute `style-site` through its reference workflow.\n   New pages update navigation by default unless the user explicitly asks not to. Resolve\n   placement through the webpage reference and include it or the explicit opt-out in the\n   page operation's existing inputs and summary before approval.\n   For new-site design, map the proposed layout to actual native composition operations on Home\n   and the primary journey. Include web-template\u002Fpage-template or shared-shell work when that\n   source owns the layout; reusing a form\u002Flist\u002Fsnippet does not require retaining its whole page.\n   Include planned section\u002Fcomponent removals and their rationale in operation summaries and\n   resolved inputs; use supported native `replace` or scoped `modify` operations, not invented\n   deletion actions or CSS hiding. Retain required source\u002Fbindings and explicit exceptions in `preserve`.\n   A plan containing only copy\u002Fimage substitutions, additional pages and styling while leaving\n   the starter Home\u002Flayout intact is incomplete unless that scope was explicitly preserved.\n3. Order operations by actual dependencies, not by skill name. Assets\u002Fsnippets\u002Ftemplates normally\n   precede their consumers; webpage metadata must create an exact localized copy file before\n   `author-webpage-content` fills it; styling runs after structural authoring.\n   Include planned header snippet\u002Ftemplate changes in those dependencies before final styling.\n   CSS-only header treatment needs no dummy structural operation or website-binding change.\n4. Follow the plan contract and write a schema-version-1 JSON plan, including the complete\n   `assets` manifest and, for a new-site handoff, the complete `newSiteDesign` brief, into a fresh external review directory\n   outside the selected site root. Do not replace the canonical approved plan during review.\n\n   ```text\n   \u003CREVIEW_DIR>\u002Fplan.json\n   ```\n\n   Use the `\u003CPROJECT_ROOT>` resolved in Phase 1. Use a new review directory for every revision so\n   the renderer never overwrites reviewed bytes.\n   New-site styling operations must depend on all structural operations, directly or transitively.\n   Plan page\u002Fsection\u002Fsite placement through `style-site`; do not replace Bootstrap, `theme.css`,\n   or `portalbasictheme.css`, flatten native markup, or install a second CSS framework to achieve\n   SPA visual quality.\n5. Never write free-form unresolved values such as `TBD`, `heroImage`, `appropriate page`, or\n   `choose a snippet`. Use typed `outputBindings` for values produced by earlier operations;\n   otherwise resolve the value or stop with the exact missing input.\n6. Render the browser plan:\n\n   ```bash\n   node \"${PLUGIN_ROOT}\u002Fscripts\u002Frender-edit-site-plan.js\" \\\n     --output \"\u003CREVIEW_DIR>\u002Fplan.html\" \\\n     --data \"\u003CREVIEW_DIR>\u002Fplan.json\"\n   ```\n\n   If either review filename exists, create a fresh review directory instead of overwriting it.\n   By default, the renderer validates the plan without image-network requests or an image-check\n   report. It labels unchecked images unverified and returns their unique URL count as\n   `unverifiedImages`. Disclose that state in the approval summary; it does not block review.\n   Do not add a mandatory verification-choice question or live-preview requirement.\n\n   Only when the user requests source verification, append `--verifyImages true`. The verifier\n   checks each unique external URL once with bounded public-only HTTPS GETs and writes\n   `plan.html.image-checks.json` after all checks succeed. See the visual-asset reference for\n   limits and evidence semantics. If a check fails, do not request approval or silently disable\n   checks. Choose a working direct source URL, update every affected asset and consumer input,\n   and render a fresh review. Do not repeatedly retry a 404, silently drop required imagery, or\n   claim an unchecked URL is verified.\n7. Open the rendered HTML with the OS-native default-browser launcher. A launch failure does not\n   invalidate the plan; print the exact path as a fallback.\n\n## Phase 4: Approve the plan\n\nPresent a short terminal summary and direct the user to the HTML for the complete user-facing\nproposal: header treatment when in scope, pages and navigation, content and page compositions,\nassets and reusable components,\nstyling, preservation decisions, warnings, verification, and the local\u002Flive boundary. The HTML\ndescribes visible outcomes rather than authoring-skill mechanics. Do not include an inline\ntechnical implementation trace. Keep the complete execution details in the validated JSON,\nwhich remains the execution source of truth and is persisted after approval.\n\n\u003C!-- gate: edit-site:4.approve | category=plan | cancel-leaves=plan-artifacts -->\n\n> ? **Gate (plan · edit-site:4.approve):** Approve the coordinated\n> customization plan before executing any authoring operation.\n>\n> **Trigger:** JSON and HTML plan artifacts are complete, with external images explicitly\n> unverified or supported by successful requested checks for this exact plan.\n> **Why:** The next phase can create or modify several related non-SPA records.\n> **Cancel leaves:** External review artifacts only; the downloaded site and current approved plan\n> remain unchanged.\n\nUse `AskUserQuestion`:\n\n| Question | Header | Options |\n|---|---|---|\n| Does this non-SPA site customization plan look good? | Customization plan | Approve and customize, Revise plan, Cancel |\n\nOn revision, create a fresh review directory, render and open it, and repeat approval. Never edit\nthe rendered HTML as the source of truth.\n\nAfter approval, publish the approved JSON:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpromote-edit-site-plan.js\" \\\n  --projectRoot \"\u003CPROJECT_ROOT>\" \\\n  --data \"\u003CAPPROVED_REVIEW_DIR>\u002Fplan.json\"\n```\n\nIf the approved review included source checks, append\n`--imageChecks \"\u003CAPPROVED_REVIEW_DIR>\u002Fplan.html.image-checks.json\"`; otherwise omit it.\n\nThe publisher validates the approved JSON, renders canonical HTML from that exact data, creates\n`current-execution.json`, and records hashes plus a run ID. When a current approved run exists, it\narchives the plan, HTML, execution receipt, and icon together before replacement. Use only the\npublished current plan and execution receipt for authoring coordination.\nThe publisher makes no image-network requests. Unchecked images remain explicitly unverified\nin the canonical HTML and command result. A supplied report must match the exact plan and contain\nsuccessful checks; it is copied into the execution receipt. Missing, malformed, stale or failed\nsupplied reports block publication, never silently downgrade it. Preserve the reviewed evidence\nstate; do not drop a checked review's report or invent one for unchecked images. Changed plans\nneed fresh review and approval, and fresh checks if requested.\n\n## Phase 5: Execute through owning workflows\n\nFor each ready operation:\n\n1. Run the execution helper with `--action resolve`; it blocks until dependencies are complete and\n   returns the operation plus effective `resolvedInputs` combining approved static inputs with\n   actual bound outputs.\n2. Mark the operation `start`, then use the non-SPA authoring index to dispatch that resolved\n   operation. Execute reference workflows directly; invoke only\n   `author-webpage-content` as a skill. Supply the approved `designContext` when\n   returned. Carry its new-site composition and explicit preservation\n   decisions, not an implicit instruction to retain the creation template's layout or branding.\n   The shared brief supplies Bootstrap and visual direction, not permission to change unrelated\n   records, discard required capabilities\u002Fcontent, or bypass the owner's approval.\n   If returned, also pass `imageChecks`: reuse these source checks for unchanged URLs instead of\n   probing once per child or placement. Keep local caller\u002FURL verification and browser failure\n   handling. Previously approved receipts without this optional field remain resumable, but do\n   not claim their image sources were checked. An unchecked new plan has the same resumable\n   behavior. A source change needs a new approved plan, with fresh checks if requested.\n3. Retain the exact selected site root, action, target identity, locales, final values, callers,\n   and preservation requirements. For a covered-skill handoff, include\n   `previewNoticeShown: true` and `invocationSource: edit-site`.\n   The operation may be expressed as structured\n   YAML\u002FJSON or unambiguous natural language; it must resolve the same decisions as the plan\n   contract.\n4. Revalidate every supplied path and existing ID before writing; require\n   the same check in child-skill handoffs.\n5. After completion, re-read the changed files, write actual stable outputs to a temporary JSON\n   object, and mark the operation `complete --outputs \u003Cpath>`. Remove that temporary file after the\n   receipt is updated.\n6. On failure, mark the operation `fail` with the concise error and stop. Do not silently adapt\n   dependent operations to an unapproved structural change. On a later session, inspect any\n   partial files before restarting that failed operation; never blindly replay it.\n7. After all operations complete, run the execution helper with `--action finish`.\n\nExecute the `author-webpage` reference workflow for page records, routes, parents, template\nassignment, localized shells, and navigation within the approved scope. Invoke `author-webpage-content` after\nthat workflow resolves the page handoff. Invoke it directly only when one exact existing localized target\nfile and its composition are already resolved.\nCarry the verified Bootstrap major through the page-owner handoff into section\u002Felement authoring.\nUse Bootstrap 5 serialization for the verified new-site default and the inspected site-local\nBootstrap 3 patterns only for the explicit compatibility path.\n\nFor every staged visual asset, execute the `author-web-file` reference workflow before its consumers and record the\nverified `publicUrl`. Dependent page, snippet, template, or styling operations must consume that\nURL through an approved `outputBindings` entry; never predict a Web File URL. For a global logo or\nfavicon, update only the exact verified snippet, template, or setting callers. Resolve all approved\ndesktop\u002Fmobile logo variants and requested locales, including the accessible brand name and\nhome-link destination; do not assume one logo snippet covers every header state. Do not replace the\nwhole header merely to change a logo, and preserve navigation, search, language selection,\nsign-in behavior, and authenticated\u002Fanonymous branches.\n\nFor external images, pass the exact approved HTTPS URL directly to the native content owner.\nFollow **External image** in the image-component reference; keep responsive sizing and localized\nalt text, and do not invent local filenames or Web File `name` attributes. External CSS image\nURLs also belong in `style-site`'s exact `externalResources` review. `style-site` does not fetch\nthem or replace the image component.\n\nFor styling, execute the `style-site` reference workflow last. Its exact-diff\u002Fhash approval is a separate binding between\nthe user-reviewed CSS proposal and the bytes applied; the customization-plan approval does not\nreplace that safety gate.\n\nDo not execute an empty operation, and do not invoke deployment from this phase.\n\n## Phase 6: Verify the combined result\n\n1. Require every component workflow's and child skill's own verification to succeed.\n2. Re-run non-SPA site discovery and confirm the selected root and website identity are\n   unchanged.\n3. Verify planned files and records exist, generated identities are unique, locale scope matches\n   the plan, dependencies resolve, and unrequested callers\u002Fcontent remain unchanged. For Web File assets,\n   verify the approved SHA-256, file\u002FYAML pair, MIME type, dimensions, public URL, localized alt\n   text, caller placement, and absence of unapproved SVG active content or Design Studio\n   placeholders.\n   For external images, verify the caller's decoded URL equals the approved `externalUrl`, alt\n   text and layout\u002Fcrop intent are present, and no image cache, binary, YAML or import operation\n   was introduced. The plan hashes the URL, not mutable remote bytes; availability and CSP remain\n   pending runtime checks unless separately performed.\n4. Review the complete Git diff against the approved plan. Unexpected component categories or\n   unrelated changes block completion. Classify `docs\u002Fedit-site\u002F**` separately as\n   orchestration evidence; it is not a PAC component category and is not uploaded.\n5. Run the create-site non-SPA validator when a website record ID is available:\n\n   ```bash\n   node \"${PLUGIN_ROOT}\u002Fskills\u002Fcreate-site\u002Fscripts\u002Fvalidate-site.js\" \\\n     --projectRoot \"\u003CPROJECT_ROOT>\" \\\n     --websiteRecordId \"\u003CWEBSITE_RECORD_ID>\"\n   ```\n\n   For `newSiteDesign`, append `--bootstrapVersion \"\u003CnewSiteDesign.bootstrapMajor>\"`.\n6. For a new-site design, compare the result with every approved brief decision and image\n   placement: approved image URLs and callers (or reused existing assets), meaningful localized alternative text, responsive\n   sizing\u002Fcrops, readable text on every intended surface, and consistent hierarchy\u002Fspacing.\n   Reuse `style-site`'s local contrast checks and resolve known failures. Report desktop\u002Fmobile\n   rendering, Studio save\u002Freopen, and unknown image-overlay contrast as pending separate live\n   checks; do not start a server or claim local validation proves visual fidelity.\n   For any planned header work, trace its branding, source and styling decisions to the changed\n   native files and retained navigation, authentication, locale and caching contracts. Confirm the\n   approved logo or wordmark in every resolved desktop\u002Fmobile caller and requested locale,\n   including its source\u002Fvalue, accessible name, link destination and responsive sizing intent.\n   An unchanged starter logo is incomplete when the plan approved its replacement. Report\n   missing planned header work as incomplete; mobile-menu, keyboard and live-state behavior\n   remain unverified until separately observed.\n7. Compare the completed composition with the approved experience brief once, using\n   `${PLUGIN_ROOT}\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-critique.md`'s native interpretation of the\n   shared categories and source-only evidence.\n   Trace the planned Home\u002Fprimary-journey section structure and reused-component placements to\n   the changed native files, including the source that actually owns the shell. Compare against\n   the downloaded baseline: copy\u002Fimage swaps or CSS on an unchanged starter layout do not satisfy\n   a custom-layout brief. Record missing planned composition work as incomplete and return it to\n   its native owner through the existing revision\u002Fapproval flow, not a completed modern design.\n   Verify that approved removals are absent from the authored source, not merely hidden by CSS,\n   and that required components, their dependencies and explicitly preserved regions remain intact.\n   A changed section count or new class name alone is not evidence of custom composition.\n   Reuse child verification and, when present, the approved image-check receipt; do not repeat unchanged network\n   probes, add a screenshot gate, or run a critique per operation. Report observed local gaps and\n   unobserved runtime checks separately, retaining unverified status for unchecked images.\n   Revisions still require the existing plan\u002Fowner approvals;\n   a low or provisional visual score does not authorize direct edits or deployment.\n\n## Phase 7: Commit, report, and offer deployment\n\nCommit coherent customization units rather than combining the untouched template baseline with\nnew work. Do not commit unrelated pre-existing changes.\n\nReport:\n\n- site identity and local root;\n- current approved plan, HTML, and execution paths, plus any archived predecessor;\n- created and modified components grouped by authoring operation;\n- languages and routes affected;\n- validation and commit results;\n- warnings and pending runtime checks;\n- explicit state: local customization is not live until deployment succeeds.\n\n\u003C!-- gate: edit-site:7.deploy | category=plan | cancel-leaves=local-customization -->\n\n> ? **Gate (plan · edit-site:7.deploy):** Choose whether to dispatch the\n> verified local non-SPA project to `\u002Fdeploy-site`.\n>\n> **Trigger:** Local customization and combined verification succeeded.\n> **Why:** Deployment has its own environment and final-upload consent gates.\n> **Cancel leaves:** Verified local customization and commits.\n\nAsk: **Deploy these non-SPA site changes now?** Options: **Deploy now**, **Keep changes\nlocal**. On deploy, invoke `\u002Fdeploy-site` with the exact project root. Otherwise finish with the\nlocal\u002Flive distinction.\n\nRecord normal successful usage as `EditSite` through\n`${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md`.\n",{"name":5,"model":57,"description":7,"allowed-tools":58,"user-invocable":59},"opus","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",true,"main","0a55a88fa2855404029d1e5450faf92878baf763","plugins\u002Fpower-pages\u002Fskills\u002Fedit-site",232,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills","https:\u002F\u002Fmicrosoft.github.io\u002Fpower-platform-skills\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 21:46:39",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":59},[72,75,78],{"tool":73,"command":74},"npx","npx skills add microsoft\u002Fpower-platform-skills --skill edit-site",{"tool":76,"command":77},"bunx","bunx skills add microsoft\u002Fpower-platform-skills --skill edit-site",{"tool":79,"command":80},"pnpm","pnpm dlx skills add microsoft\u002Fpower-platform-skills --skill edit-site","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002FSKILL.md",[83,89,95,99,103,107,111,115,119,123,127,131,135,139,143,147,151,155,159,163,167],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"assets\u002Fcustomization-plan.html","ASSET","资产文件",33537,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Fassets\u002Fcustomization-plan.html",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fcontent-and-page-compositions.md","REFERENCE","参考文档",16769,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fcontent-and-page-compositions.md",{"path":96,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fcontent-snippet-authoring.md",30177,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fcontent-snippet-authoring.md",{"path":100,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fcustomization-plan-contract.md",27837,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fcustomization-plan-contract.md",{"path":104,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fnon-spa-site-authoring.md",9046,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fnon-spa-site-authoring.md",{"path":108,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fpage-template-authoring.md",19360,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fpage-template-authoring.md",{"path":112,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fsite-marker-authoring.md",11654,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fsite-marker-authoring.md",{"path":116,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fstyle-site-workflow.md",5506,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyle-site-workflow.md",{"path":120,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fstyling\u002Fbootstrap-and-studio.md",11127,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fbootstrap-and-studio.md",{"path":124,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":125,"sourceHtmlUrl":126},"references\u002Fstyling\u002Fdesign-critique.md",6438,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-critique.md",{"path":128,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":129,"sourceHtmlUrl":130},"references\u002Fstyling\u002Fdesign-quality.md",15657,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fdesign-quality.md",{"path":132,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":133,"sourceHtmlUrl":134},"references\u002Fstyling\u002Fproposal-and-verification.md",54767,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fproposal-and-verification.md",{"path":136,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":137,"sourceHtmlUrl":138},"references\u002Fstyling\u002Fquick-start.md",6070,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fquick-start.md",{"path":140,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":141,"sourceHtmlUrl":142},"references\u002Fstyling\u002Fruntime-dom-discovery.md",16084,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fruntime-dom-discovery.md",{"path":144,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":145,"sourceHtmlUrl":146},"references\u002Fstyling\u002Fsources.md",10804,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fsources.md",{"path":148,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":149,"sourceHtmlUrl":150},"references\u002Fstyling\u002Fstudio-component-capabilities.md",12337,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fstudio-component-capabilities.md",{"path":152,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":153,"sourceHtmlUrl":154},"references\u002Fstyling\u002Fstyling-policy.md",16723,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fstyling\u002Fstyling-policy.md",{"path":156,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":157,"sourceHtmlUrl":158},"references\u002Fvisual-asset-planning.md",17857,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fvisual-asset-planning.md",{"path":160,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":161,"sourceHtmlUrl":162},"references\u002Fweb-file-authoring.md",22270,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fweb-file-authoring.md",{"path":164,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":165,"sourceHtmlUrl":166},"references\u002Fweb-template-authoring.md",21770,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fweb-template-authoring.md",{"path":168,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":169,"sourceHtmlUrl":170},"references\u002Fwebpage-authoring.md",22694,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fedit-site\u002Freferences\u002Fwebpage-authoring.md",[172,193,216,234,248,258],{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":52},"01M699WVHX0XN59EPBTTPEKYPG","setup","Use when Process Intelligence needs building, explicit cloud\u002Faccount\u002Fenvironment configuration, sign-in, connection diagnostics, or recovery from an authentication error.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fsetup\u002FSKILL.md",[],[174,179,180,181,182,183,184,185,186,187,188,189,190,191,192,39],"read","when","connection","error","sign","intelligence","configuration","use","process","diagnostics","environment","authentication","cloud","recovery",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":204,"publishedAt":52},"01M699WSR9EX55YY1WD9J22FEG","report-issue","Use when the user wants a Process Intelligence bug-report draft or support summary for a failed operation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Freport-issue\u002FSKILL.md",[199],{"categoryNo":200,"categoryName":201,"taxonomyType":202,"taxonomyTypeDesc":203},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[205,206,207,208,209,187,186,210,211,184,212,213,214,180,215],"report issue","report","issue","support","user","bug","summary","draft","operation","for","bug-report",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":222,"publishedAt":52},"01M699WR26YQ9Q21KE6MJF5B2G","investigate-process","Use when a broad Process Mining business question, observed pattern or competing explanation needs investigation across analytical perspectives.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Finvestigate-process\u002FSKILL.md",[],[187,223,224,225,180,226,227,228,229,179,230,186,231,232,233],"investigate","investigate process","mining","process mining","investigation","perspectives","question","business","pattern","across","analytical",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":240,"publishedAt":52},"01M699WP9SDG5ZR12P8VYNXKTN","derive-metric","Use when a requested measure is missing, a saved custom metric needs reuse, or an ephemeral formula or derived scalar is needed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fderive-metric\u002FSKILL.md",[],[241,242,179,186,243,244,245,246,247,180],"metric","derive metric","formula","missing","reuse","saved","custom",{"skillNo":249,"name":250,"nameZh":6,"description":251,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":252,"categories":253,"keywords":254,"publishedAt":52},"01M699WMG5R8P6SMTDAS1TKF9E","compare-cohorts","Use when comparing process cohorts, departments, periods or before-and-after results under matched definitions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fcompare-cohorts\u002FSKILL.md",[],[255,256,180,186,187,257,179],"compare","compare cohorts","results",{"skillNo":259,"name":260,"nameZh":6,"description":261,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":262,"categories":263,"keywords":264,"publishedAt":52},"01M699WJWNVTMP9XK3NCJHV14D","analyze-variants","Use when investigating common or slow variants, repeated work, unusual paths, or a specific Process Mining case.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fanalyze-variants\u002FSKILL.md",[],[265,266,267,226,180,225,268,269,186,187,179,270,271],"analyze","variants","analyze variants","case","paths","work","common"]