[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699VDE7HF4T4T96TN0MAC5F":3,"skill-same:01M699VDE7HF4T4T96TN0MAC5F":114},{"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":23,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":79},"01M699VDE7HF4T4T96TN0MAC5F","migrate-webapi-selectall",null,"Reviews and migrates deprecated wildcard (*) values in Power Pages Web API fields site settings to least-privilege explicit Dataverse columns. Use whenever a user mentions Web API wildcard or select-all remediation, fields settings containing *, data-exposure review, wildcard deprecation readiness, or Web API failures after wildcard retirement. Applies to both non-SPA sites using HTML, CSS, JavaScript, Liquid, and downloaded YAML, and SPA sites using React, Vue, Angular, Astro, or TypeScript. The agent must inspect every source Web API call and consumer, report exact fixes for every wildcard, report every already-explicit configuration, apply approved edits, and verify no wildcard remains.","microsoft\u002Fpower-platform-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699JVYJFB75D9JM70BN4H0Q",1146,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"migrate webapi selectall","migrate","astro","deprecation","inspect","reviews","spa","project","power","write","read","select","Bash","review","api","angular","remediation","power pages","dataverse","react","web","javascript","typescript","css","2026-11-10 10:12:30",false,"---\nname: migrate-webapi-selectall\ndescription: >-\n  Reviews and migrates deprecated wildcard (*) values in Power Pages Web API\n  fields site settings to least-privilege explicit Dataverse columns.\n  Use whenever a user mentions Web API wildcard or select-all remediation,\n  fields settings containing *, data-exposure review, wildcard deprecation\n  readiness, or Web API failures after wildcard retirement. Applies to both\n  non-SPA sites using HTML, CSS, JavaScript, Liquid, and downloaded YAML,\n  and SPA sites using React, Vue, Angular, Astro, or TypeScript. The agent must\n  inspect every source Web API call and consumer, report exact fixes for every\n  wildcard, report every already-explicit configuration, apply approved edits,\n  and verify no wildcard remains.\nuser-invocable: true\nargument-hint: Optional Power Pages project path\nallowed-tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, TaskCreate, TaskUpdate, TaskList\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\n# Migrate Power Pages Web API Wildcards\n\nReplace every deprecated `Webapi\u002F\u003Ctable>\u002Ffields = *` value with the smallest\nexplicit column set proven by the site's actual Web API behavior.\n\nThe LLM owns source discovery, call-chain reasoning, field decisions, report\nwriting, and edits. Use the bundled script only to retrieve authoritative\nDataverse table schema; it must not decide which columns the code needs.\n\nSupport both:\n\n- non-SPA sites with HTML, JavaScript, Liquid, web templates, and\n  aggregate YAML;\n- SPA sites with React, Vue, Angular, Astro, TypeScript, downloaded\n  deployment YAML, or mixed custom JavaScript.\n\n**Initial request:** $ARGUMENTS\n\n## Non-negotiable rules\n\n1. Review every discovered source table Web API call, including shared\n   wrappers, dynamic builders, and response consumers.\n2. Review every configuration scope and deployment-profile copy.\n3. Map request `EntitySetName` values to setting logical names using table\n   schema. Never singularize, pluralize, or guess.\n4. Treat `*` as unsupported for reads, writes, aggregates, FetchXML, files,\n   and images.\n5. Give every wildcard an exact proposed replacement before editing anything.\n6. Report every already-explicit fields setting, including missing and\n   potentially unnecessary columns.\n7. Never apply a partial wildcard plan. Resolve all wildcards and call-site\n   rows first.\n8. Keep reports free of absolute local paths, tokens, URLs, data values,\n   filter literals, request bodies, response bodies, and source snippets, and\n   build them only by rendering the bundled template with the bundled script.\n9. Preserve unrelated YAML structure and values.\n10. Verify with a fresh discovery pass, not remembered inventory.\n11. Leave only the rendered report and its icon in the migration output\n    directory.\n12. Never download or upload site content until the user has explicitly\n    confirmed the environment, website, site type, data model, and deployment\n    profile. Neither transfer can be reverted.\n13. Run smoke tests only after explicit approval, and never issue POST, PATCH,\n    PUT, or DELETE Web API calls against a deployed site. Testing a write\n    destroys real record data.\n\nRead [references\u002Fcolumn-analysis.md](references\u002Fcolumn-analysis.md) before\nanalyzing calls. Read\n[references\u002Fconfiguration-and-reporting.md](references\u002Fconfiguration-and-reporting.md)\nbefore inventorying settings or writing the report. Read\n[references\u002Fsite-transfer.md](references\u002Fsite-transfer.md) before any download\nor upload.\n\n## Phase 1: Prepare\n\n**Goal:** Resolve the project, confirm the site, and protect existing work.\n\n1. Create all seven tasks from [Progress tracking](#progress-tracking).\n2. Resolve `PROJECT_ROOT` from `$ARGUMENTS` or the current directory.\n3. Detect site markers independently:\n   - `powerpages.config.json` indicates an SPA site;\n   - root `website.yml`, root `sitesetting.yml`, or `.powerpages-site\u002F`\n     indicates downloaded non-SPA artifacts;\n   - when both appear, scan both layouts.\n4. Read `.solution-manifest.json` when present. This migration changes existing\n   settings; do not create or select another solution.\n5. Inspect git status. Never discard, hide, or include unrelated user changes.\n6. Run `node --version`.\n7. Confirm `assets\u002Fmigration-report-template.html` and\n   `scripts\u002Frender-migration-report.js` are readable, and stop if either is\n   missing.\n8. Read [references\u002Fsite-transfer.md](references\u002Fsite-transfer.md), then\n   confirm the environment, website name and `WebSiteId`, site type, data\n   model, deployment profile, and target path with the user. Check each\n   against `pac auth who`, `pac env who`, and `pac pages list`, and stop on\n   any mismatch. Never infer one from a folder name or an active default.\n\nAnalyzing the wrong site produces confident, wrong fixes, so settle identity\nbefore reading any setting. Download only when the user wants a fresh copy or\n`PROJECT_ROOT` holds no site content; downloading replaces local files and\ncannot be reverted.\n\n\u003C!-- gate: migrate-webapi-selectall:1.download-site | category=consent | cancel-leaves=nothing -->\n\n> ? **Gate (consent · migrate-webapi-selectall:1.download-site):** Approve the download only after displaying the confirmed environment, website name and ID, site type, data model, target path, and the exact command. Canceling leaves local content untouched and continues against the existing copy.\n\nUse `AskUserQuestion`: `Download the confirmed site` or `Use the local copy`.\nRepeat step 3 after any download.\n\n**Output:** Project root, site layouts, solution context, git state, confirmed\nsite identity, and a downloaded copy when approved.\n\n## Phase 2: Build the complete inventory\n\n**Goal:** Find every configuration and candidate source Web API call before\nreasoning about columns.\n\n### 2.1 Inventory configuration scopes\n\nUse `Glob`, `Grep`, and `Read` to inspect:\n\n- every `sitesetting.yml`;\n- every `*.sitesetting.yml`;\n- `.powerpages-site\u002Fsite-settings\u002F`;\n- deployment-profile and environment-specific copies.\n\nRecord every `Webapi\u002F\u003Ctable>\u002Ffields` and `Webapi\u002F\u003Ctable>\u002Fenabled` entry with\nits relative file, line, scope, key style, and current value. Classify fields\nsettings as:\n\n- `wildcard`;\n- `explicit`;\n- `missing` for an enabled table;\n- `duplicate` only within the same configuration scope.\n\nDo not treat identical settings in different deployment profiles as\nduplicates. Record every profile name and which settings it overrides. Never\nassume the `default` profile is the intended deployment profile.\n\nQuery Dataverse once per unique table, never once per configuration.\n\n### 2.2 Inventory source calls\n\nAnalyze only authoritative, editable source files. Never inspect compiled or\ngenerated code.\n\nFor SPA sites:\n\n1. Read `powerpages.config.json`, `package.json`, and present framework or\n   bundler configuration before searching calls.\n2. Treat `compiledPath` and every configured build-output directory as a hard\n   exclusion.\n3. Exclude `.powerpages-site\u002Fweb-files\u002F`, `node_modules\u002F`, coverage and cache\n   directories, source maps, minified bundles, framework output directories,\n   and content-hashed assets matching\n   `\u003Centry-name>-\u003Ccontent-hash>.\u003Cextension>`.\n4. Use `.powerpages-site\u002Fsite-settings\u002F` only for configuration inventory,\n   never for source analysis.\n5. Search editable roots such as configured source directories and framework\n   application directories.\n\nFor non-SPA sites, search editable JavaScript, Liquid, web templates, web\nfiles, and other authored source. Do not exclude an authored non-SPA web\nfile merely because it is deployed as a web file.\n\nSearch source extensions including `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`,\n`.html`, `.htm`, `.liquid`, `.aspx`, `.ascx`, `.cshtml`, and XML web\ntemplates. If a call exists only in compiled, minified, generated, or\ncontent-hashed output, record a `missing-source` blocker and stop the\nmigration. Do not infer columns from that output.\n\nSearch for:\n\n- `\u002F_api\u002F`, encoded variants, split URL fragments, and API base constants;\n- `fetch`, Axios, `XMLHttpRequest`, jQuery AJAX, `webapi.safeAjax`,\n  `shell.ajaxSafePost`, and custom request wrappers;\n- entity-set constants, query builders, FetchXML builders, and body builders;\n- callers and consumers imported from other files.\n\nFor each source candidate, record relative path, line, method, endpoint\nexpression, and wrapper chain. A comment, example, or non-table endpoint still\nneeds an explicit disposition. Excluded build outputs are never recorded.\n\nWrite the settings inventory to\n`docs\u002Fwebapi-selectall-migration\u002Fmigration-report.json` and render the draft\nreport as described in\n[references\u002Fconfiguration-and-reporting.md](references\u002Fconfiguration-and-reporting.md).\nDo not propose fields yet.\n\nStop if any in-scope source or configuration file cannot be read.\n\n\u003C!-- gate: migrate-webapi-selectall:2.confirm-scope | category=plan | cancel-leaves=draft-migration-report -->\n\n> ? **Gate (plan · migrate-webapi-selectall:2.confirm-scope):** Confirm the project, configuration scopes and profiles, wildcard count, explicit-setting count, and source inventory before schema retrieval. Canceling leaves only the read-only draft report.\n\nUse `AskUserQuestion` to confirm or cancel. Expand the inventory and repeat this\nphase if the user identifies another source or deployment scope.\n\n## Phase 3: Retrieve schema and resolve columns\n\n**Goal:** Use authoritative names while letting the LLM determine actual usage.\n\n### 3.1 Retrieve only relevant table schema\n\nBuild the initial unique list containing:\n\n- logical table names from all Web API settings;\n- entity-set names from all candidate table calls;\n- entity-set names directly present in bind targets or related-table calls.\n\nDo not treat a navigation-property name as a table identifier. Its target\nlogical name is authoritative only after relationship metadata resolves it.\n\nResolve the environment URL from confirmed project context or `pac env who`.\nIf unavailable, ask for the URL as data gathering; never ask for or accept an\naccess token.\n\n\u003C!-- not-a-gate: environment URL supplies read-only metadata query input only -->\n\nWrite every deduplicated identifier, one per line, to\n`docs\u002Fwebapi-selectall-migration\u002Ftable-identifiers.txt`. Run:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fmigrate-webapi-selectall\u002Fscripts\u002Fquery-table-schema.js\" --project-root \"\u003CPROJECT_ROOT>\" --environment-url \"\u003CENVIRONMENT_URL>\" --tables-file \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fwebapi-selectall-migration\u002Ftable-identifiers.txt\" --output \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fwebapi-selectall-migration\u002Ftable-schema.json\"\n```\n\nIf an identifier does not resolve, trace the code or obtain the correct\ncontract; do not guess.\n\nAfter the initial snapshot:\n\n1. Match every used `$expand` navigation property against its source table's\n   returned relationship metadata.\n2. Collect only target logical names absent from all existing snapshots.\n3. Write those names to\n   `table-identifiers-pass-\u003CN>.txt` and query them to\n   `table-schema.pass-\u003CN>.json`.\n4. Repeat for nested expansion paths until every used navigation segment is\n   resolved.\n\nTreat `table-schema.json` and all numbered snapshots as one schema package.\nNever requery a logical table already present in that package, and never\nlaunch concurrent schema queries.\n\nIdentifier lists and schema snapshots are working files. Keep them until\nverification finishes, then delete them in Phase 7.\n\n### 3.2 Analyze every call and consumer\n\nFor every source inventory row:\n\n1. Read the complete enclosing function or template block.\n2. Trace imported wrappers, URL variables, query builders, body builders,\n   response mappers, types, components, templates, and every caller.\n3. Follow conditional branches, spreads, dynamic arrays, and runtime\n   configuration.\n4. Map the entity set to its logical table using the schema package.\n5. Apply every rule in\n   [references\u002Fcolumn-analysis.md](references\u002Fcolumn-analysis.md).\n6. Record requirements per owning logical table, not merely per request.\n7. Classify the row as `mapped`, `non-table`, or `not-a-call`.\n8. Leave the row unresolved if any runtime branch or consumer remains unknown.\n\nOne logical table is normally reached from several places. Collect every call\nsite for a table before proposing its fields: duplicated or competing\nwrappers, per-page scripts, different query shapes, and repeated calls in the\nsame file. A later call site for an already-analyzed table can still add\ncolumns, so never stop at the first one.\n\nFor normal record GETs without `$select`, derive output fields from every\nconsumer and propose a source edit adding the smallest explicit projection.\nFilters, ordering, and other query fields still belong in the fields setting,\neven when they should not be added to the output projection.\n\nKeep the response projection and fields-setting allowlist as separate sets.\nNever add a filter-only, order-only, grouping-only, or write-only column to an\nexisting `$select` unless a response consumer also reads it.\n\n### 3.3 Build configuration proposals\n\nFor each wildcard setting:\n\n1. Union the proven requirements from every call site that reaches that\n   logical table within the applicable site behavior.\n2. Validate each proposed name against the schema package.\n3. Link every proposed column to source path and line or a user-confirmed\n   external contract.\n4. Produce the exact replacement:\n\n   ```text\n   Webapi\u002F\u003Ctable>\u002Ffields = \u003Ccolumn-name-1>,\u003Ccolumn-name-2>,\u003Ccolumn-name-3>\n   ```\n\n5. Keep the proposal unresolved if it is empty or any evidence is incomplete.\n\nFor each already-explicit setting:\n\n- compare configured columns with proven required columns;\n- classify it as exact, missing required columns, potentially overbroad, or\n  externally justified;\n- include an exact proposed fix for every gap;\n- do not silently change it.\n\nUpdate the report. Resolve all wildcard and call-site rows before continuing.\n\n**Output:** Evidence-complete report with exact wildcard replacements and all\nalready-explicit configurations.\n\n## Phase 4: Review the complete plan\n\n**Goal:** Present the full exposure reduction before edits.\n\nShow:\n\n- wildcard issues found and the exact replacement for each;\n- evidence for every proposed column;\n- source GETs requiring `$select`;\n- already-explicit settings and any missing or excess columns;\n- any missing or duplicate settings found during inventory;\n- zero unresolved call sites.\n\n\u003C!-- gate: migrate-webapi-selectall:4.apply-plan | category=consent | cancel-leaves=reviewed-migration-report -->\n\n> ? **Gate (consent · migrate-webapi-selectall:4.apply-plan):** Approve all wildcard replacements, required source projections, optional explicit-setting hardening, and local edits. Canceling preserves only the report.\n\nUse `AskUserQuestion` with:\n\n- `Apply all wildcard fixes and approved explicit fixes`;\n- `Apply all wildcard fixes only`;\n- `Cancel`.\n\nNever offer a subset of wildcard fixes.\n\n## Phase 5: Apply approved edits\n\n**Goal:** Update source projections and every wildcard setting.\n\n1. Use `Edit` to add approved `$select` projections. Preserve methods, filters,\n   ordering, expansion, pagination, encoding, Liquid expressions, and error\n   handling.\n2. Use `Edit` to replace every wildcard value in every scope and profile.\n   Preserve identifiers, key names, quoting, indentation, comments, and\n   unrelated values.\n3. Apply already-explicit changes only when included in the selected approval.\n4. Re-read every changed block immediately and update report status.\n\nIf any edit fails or a file changed since review, stop. Do not continue with a\npartial configuration set and do not perform a broad rollback over user work.\n\n**Output:** All approved local edits and updated report.\n\n## Phase 6: Verify independently\n\n**Goal:** Prove the migration without trusting prior notes.\n\n1. Repeat Phase 2 discovery from scratch.\n2. Confirm every configuration scope contains zero\n   `Webapi\u002F\u003Ctable>\u002Ffields` wildcard values.\n3. Compare each migrated value with its approved exact replacement.\n4. Reopen every call site and replay the coverage analysis:\n   - mapped table and method remain correct;\n   - required setting columns are present;\n   - normal record GETs use explicit `$select`;\n   - expanded, lookup, write, FetchXML, file, and image columns remain covered.\n5. Run the existing project build for SPA sites. For non-SPA sites,\n   inspect edited JavaScript and Liquid syntax and use existing site tests when\n   available.\n6. Finalize the report status and every entry status, then delete the previous\n   `migration-report.html` and re-render it from the updated data file.\n\nDo not claim full hardening while explicit configuration gaps remain. Use the\npartial status defined in the reporting contract when applicable.\n\n**Output:** Final report and verified local migration.\n\n### Final site-integrity gate\n\nAfter all approved source edits, independent verification, and the SPA build\nare complete, run:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fvalidate-site-integrity.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nFix every blocking error before claiming the migration is complete or offering\ndeployment. Inspect and report review findings in both directions and with\nexpanded content. Rerun this gate after any later source change.\n\n## Phase 7: Deploy and summarize\n\n**Goal:** Publish only verified changes.\n\nRe-confirm every identity detail in\n[references\u002Fsite-transfer.md](references\u002Fsite-transfer.md) with the user\nimmediately before uploading, and display the exact command. Select the\ndeployment profile the user reviewed, and use `default` only when they name\nit. Any change of environment, website, data model, or profile requires a\nseparate deployment approval.\n\n\u003C!-- gate: migrate-webapi-selectall:7.deploy | category=final | cancel-leaves=local-migration -->\n\n> ? **Gate (final · migrate-webapi-selectall:7.deploy):** Approve the verified migration for the displayed environment, website, site type, data model, and deployment profile. Canceling preserves local edits and the final report without changing the live site.\n\nUse `AskUserQuestion`: `Deploy now` or `Keep local only`.\n\n- Re-run `pac auth who` and `pac env who`, and stop on any mismatch.\n  `pac pages upload-code-site` accepts no `--environment` and targets whatever\n  the active authentication profile reports.\n- For SPA sites, confirm `.powerpages-site` contains the approved\n  configuration edits, run the existing production build, then run\n  `pac pages upload-code-site --rootPath \"\u003CPROJECT_ROOT>\" --siteName\n  \"\u003CSITE_NAME>\"`.\n- For non-SPA sites, run `pac pages upload --path \"\u003CPROJECT_ROOT>\"\n  --environment \"\u003CENVIRONMENT>\" --modelVersion \"\u003CStandard|Enhanced>\"\n  --deploymentProfile \"\u003CPROFILE>\"`.\n\nNever substitute one upload command for the other. Each corrupts the other\nsite type, and the damage cannot be reverted.\n\nAfter deployment, list the read paths a smoke test would exercise: GET calls,\n`$select` projections, `$expand`, FetchXML, and aggregates. Never run one\nunprompted.\n\n\u003C!-- gate: migrate-webapi-selectall:7.smoke-test | category=progress | cancel-leaves=deployed-migration-unverified -->\n\n> ? **Gate (progress · migrate-webapi-selectall:7.smoke-test):** Approve the listed read-path smoke test against the deployed site. Canceling skips it and reports the deployed migration as unverified.\n\nUse `AskUserQuestion`: `Run the read-path smoke test` or `Skip verification`.\n\nNever issue write, file, or image requests. Ask the user to exercise those\npaths themselves against disposable records.\n\nTreat HTTP 403 responses as evidence to investigate and never restore `*`. Do\nnot add a column under the prior approval. Return to Phase 3, update the exact\nplan and report, repeat the Phase 4 approval, independently verify in Phase 6,\nand obtain a new Phase 7 deployment approval.\n\nDelete every working file created during the migration, keeping only\n`docs\u002Fwebapi-selectall-migration\u002Fmigration-report.html` and the\n`power-pages-icon.png` the renderer places beside it:\n\n- `table-identifiers.txt` and `table-identifiers-pass-\u003CN>.txt`;\n- `table-schema.json` and `table-schema.pass-\u003CN>.json`;\n- `migration-report.json`.\n\nDelete only files this migration created, and confirm the directory holds the\nreport and its icon alone. Skip cleanup while returning to an earlier phase,\nand delete the regenerated files once that pass finishes.\n\nRecord usage by following\n`${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md` with\n`--skillName \"MigrateWebapiSelectall\"`.\n\nSummarize wildcard counts, explicit reviews, source edits, report path,\nverification, deployment, and every path left unverified.\n\n## Progress tracking\n\nCreate these tasks before Phase 1:\n\n| Task subject | activeForm | Description |\n|---|---|---|\n| Prepare migration project | Preparing migration project | Confirm the site, then resolve layouts and git state |\n| Inventory Web API usage | Inventorying Web API usage | Find every configuration and source call |\n| Resolve actual columns | Resolving actual columns | Retrieve schema and trace every consumer |\n| Review migration plan | Reviewing migration plan | Present exact fixes and evidence |\n| Apply approved migration | Applying approved migration | Edit projections and configurations |\n| Verify migration results | Verifying migration results | Repeat discovery, build, and finalize report |\n| Deploy and summarize | Deploying and summarizing | Publish after approval and report outcome |\n\nMark each task `in_progress` when starting and `completed` when finished.\n\n---\n\n**Begin with Phase 1: Prepare.**\n","> **Plugin check**: Run `node \"${PLUGIN_ROOT}\u002Fscripts\u002Fcheck-version.js\"` — if it outputs a message, show it to the user before proceeding.\n\n# Migrate Power Pages Web API Wildcards\n\nReplace every deprecated `Webapi\u002F\u003Ctable>\u002Ffields = *` value with the smallest\nexplicit column set proven by the site's actual Web API behavior.\n\nThe LLM owns source discovery, call-chain reasoning, field decisions, report\nwriting, and edits. Use the bundled script only to retrieve authoritative\nDataverse table schema; it must not decide which columns the code needs.\n\nSupport both:\n\n- non-SPA sites with HTML, JavaScript, Liquid, web templates, and\n  aggregate YAML;\n- SPA sites with React, Vue, Angular, Astro, TypeScript, downloaded\n  deployment YAML, or mixed custom JavaScript.\n\n**Initial request:** $ARGUMENTS\n\n## Non-negotiable rules\n\n1. Review every discovered source table Web API call, including shared\n   wrappers, dynamic builders, and response consumers.\n2. Review every configuration scope and deployment-profile copy.\n3. Map request `EntitySetName` values to setting logical names using table\n   schema. Never singularize, pluralize, or guess.\n4. Treat `*` as unsupported for reads, writes, aggregates, FetchXML, files,\n   and images.\n5. Give every wildcard an exact proposed replacement before editing anything.\n6. Report every already-explicit fields setting, including missing and\n   potentially unnecessary columns.\n7. Never apply a partial wildcard plan. Resolve all wildcards and call-site\n   rows first.\n8. Keep reports free of absolute local paths, tokens, URLs, data values,\n   filter literals, request bodies, response bodies, and source snippets, and\n   build them only by rendering the bundled template with the bundled script.\n9. Preserve unrelated YAML structure and values.\n10. Verify with a fresh discovery pass, not remembered inventory.\n11. Leave only the rendered report and its icon in the migration output\n    directory.\n12. Never download or upload site content until the user has explicitly\n    confirmed the environment, website, site type, data model, and deployment\n    profile. Neither transfer can be reverted.\n13. Run smoke tests only after explicit approval, and never issue POST, PATCH,\n    PUT, or DELETE Web API calls against a deployed site. Testing a write\n    destroys real record data.\n\nRead [references\u002Fcolumn-analysis.md](references\u002Fcolumn-analysis.md) before\nanalyzing calls. Read\n[references\u002Fconfiguration-and-reporting.md](references\u002Fconfiguration-and-reporting.md)\nbefore inventorying settings or writing the report. Read\n[references\u002Fsite-transfer.md](references\u002Fsite-transfer.md) before any download\nor upload.\n\n## Phase 1: Prepare\n\n**Goal:** Resolve the project, confirm the site, and protect existing work.\n\n1. Create all seven tasks from [Progress tracking](#progress-tracking).\n2. Resolve `PROJECT_ROOT` from `$ARGUMENTS` or the current directory.\n3. Detect site markers independently:\n   - `powerpages.config.json` indicates an SPA site;\n   - root `website.yml`, root `sitesetting.yml`, or `.powerpages-site\u002F`\n     indicates downloaded non-SPA artifacts;\n   - when both appear, scan both layouts.\n4. Read `.solution-manifest.json` when present. This migration changes existing\n   settings; do not create or select another solution.\n5. Inspect git status. Never discard, hide, or include unrelated user changes.\n6. Run `node --version`.\n7. Confirm `assets\u002Fmigration-report-template.html` and\n   `scripts\u002Frender-migration-report.js` are readable, and stop if either is\n   missing.\n8. Read [references\u002Fsite-transfer.md](references\u002Fsite-transfer.md), then\n   confirm the environment, website name and `WebSiteId`, site type, data\n   model, deployment profile, and target path with the user. Check each\n   against `pac auth who`, `pac env who`, and `pac pages list`, and stop on\n   any mismatch. Never infer one from a folder name or an active default.\n\nAnalyzing the wrong site produces confident, wrong fixes, so settle identity\nbefore reading any setting. Download only when the user wants a fresh copy or\n`PROJECT_ROOT` holds no site content; downloading replaces local files and\ncannot be reverted.\n\n\u003C!-- gate: migrate-webapi-selectall:1.download-site | category=consent | cancel-leaves=nothing -->\n\n> ? **Gate (consent · migrate-webapi-selectall:1.download-site):** Approve the download only after displaying the confirmed environment, website name and ID, site type, data model, target path, and the exact command. Canceling leaves local content untouched and continues against the existing copy.\n\nUse `AskUserQuestion`: `Download the confirmed site` or `Use the local copy`.\nRepeat step 3 after any download.\n\n**Output:** Project root, site layouts, solution context, git state, confirmed\nsite identity, and a downloaded copy when approved.\n\n## Phase 2: Build the complete inventory\n\n**Goal:** Find every configuration and candidate source Web API call before\nreasoning about columns.\n\n### 2.1 Inventory configuration scopes\n\nUse `Glob`, `Grep`, and `Read` to inspect:\n\n- every `sitesetting.yml`;\n- every `*.sitesetting.yml`;\n- `.powerpages-site\u002Fsite-settings\u002F`;\n- deployment-profile and environment-specific copies.\n\nRecord every `Webapi\u002F\u003Ctable>\u002Ffields` and `Webapi\u002F\u003Ctable>\u002Fenabled` entry with\nits relative file, line, scope, key style, and current value. Classify fields\nsettings as:\n\n- `wildcard`;\n- `explicit`;\n- `missing` for an enabled table;\n- `duplicate` only within the same configuration scope.\n\nDo not treat identical settings in different deployment profiles as\nduplicates. Record every profile name and which settings it overrides. Never\nassume the `default` profile is the intended deployment profile.\n\nQuery Dataverse once per unique table, never once per configuration.\n\n### 2.2 Inventory source calls\n\nAnalyze only authoritative, editable source files. Never inspect compiled or\ngenerated code.\n\nFor SPA sites:\n\n1. Read `powerpages.config.json`, `package.json`, and present framework or\n   bundler configuration before searching calls.\n2. Treat `compiledPath` and every configured build-output directory as a hard\n   exclusion.\n3. Exclude `.powerpages-site\u002Fweb-files\u002F`, `node_modules\u002F`, coverage and cache\n   directories, source maps, minified bundles, framework output directories,\n   and content-hashed assets matching\n   `\u003Centry-name>-\u003Ccontent-hash>.\u003Cextension>`.\n4. Use `.powerpages-site\u002Fsite-settings\u002F` only for configuration inventory,\n   never for source analysis.\n5. Search editable roots such as configured source directories and framework\n   application directories.\n\nFor non-SPA sites, search editable JavaScript, Liquid, web templates, web\nfiles, and other authored source. Do not exclude an authored non-SPA web\nfile merely because it is deployed as a web file.\n\nSearch source extensions including `.js`, `.jsx`, `.ts`, `.tsx`, `.vue`,\n`.html`, `.htm`, `.liquid`, `.aspx`, `.ascx`, `.cshtml`, and XML web\ntemplates. If a call exists only in compiled, minified, generated, or\ncontent-hashed output, record a `missing-source` blocker and stop the\nmigration. Do not infer columns from that output.\n\nSearch for:\n\n- `\u002F_api\u002F`, encoded variants, split URL fragments, and API base constants;\n- `fetch`, Axios, `XMLHttpRequest`, jQuery AJAX, `webapi.safeAjax`,\n  `shell.ajaxSafePost`, and custom request wrappers;\n- entity-set constants, query builders, FetchXML builders, and body builders;\n- callers and consumers imported from other files.\n\nFor each source candidate, record relative path, line, method, endpoint\nexpression, and wrapper chain. A comment, example, or non-table endpoint still\nneeds an explicit disposition. Excluded build outputs are never recorded.\n\nWrite the settings inventory to\n`docs\u002Fwebapi-selectall-migration\u002Fmigration-report.json` and render the draft\nreport as described in\n[references\u002Fconfiguration-and-reporting.md](references\u002Fconfiguration-and-reporting.md).\nDo not propose fields yet.\n\nStop if any in-scope source or configuration file cannot be read.\n\n\u003C!-- gate: migrate-webapi-selectall:2.confirm-scope | category=plan | cancel-leaves=draft-migration-report -->\n\n> ? **Gate (plan · migrate-webapi-selectall:2.confirm-scope):** Confirm the project, configuration scopes and profiles, wildcard count, explicit-setting count, and source inventory before schema retrieval. Canceling leaves only the read-only draft report.\n\nUse `AskUserQuestion` to confirm or cancel. Expand the inventory and repeat this\nphase if the user identifies another source or deployment scope.\n\n## Phase 3: Retrieve schema and resolve columns\n\n**Goal:** Use authoritative names while letting the LLM determine actual usage.\n\n### 3.1 Retrieve only relevant table schema\n\nBuild the initial unique list containing:\n\n- logical table names from all Web API settings;\n- entity-set names from all candidate table calls;\n- entity-set names directly present in bind targets or related-table calls.\n\nDo not treat a navigation-property name as a table identifier. Its target\nlogical name is authoritative only after relationship metadata resolves it.\n\nResolve the environment URL from confirmed project context or `pac env who`.\nIf unavailable, ask for the URL as data gathering; never ask for or accept an\naccess token.\n\n\u003C!-- not-a-gate: environment URL supplies read-only metadata query input only -->\n\nWrite every deduplicated identifier, one per line, to\n`docs\u002Fwebapi-selectall-migration\u002Ftable-identifiers.txt`. Run:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fmigrate-webapi-selectall\u002Fscripts\u002Fquery-table-schema.js\" --project-root \"\u003CPROJECT_ROOT>\" --environment-url \"\u003CENVIRONMENT_URL>\" --tables-file \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fwebapi-selectall-migration\u002Ftable-identifiers.txt\" --output \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fwebapi-selectall-migration\u002Ftable-schema.json\"\n```\n\nIf an identifier does not resolve, trace the code or obtain the correct\ncontract; do not guess.\n\nAfter the initial snapshot:\n\n1. Match every used `$expand` navigation property against its source table's\n   returned relationship metadata.\n2. Collect only target logical names absent from all existing snapshots.\n3. Write those names to\n   `table-identifiers-pass-\u003CN>.txt` and query them to\n   `table-schema.pass-\u003CN>.json`.\n4. Repeat for nested expansion paths until every used navigation segment is\n   resolved.\n\nTreat `table-schema.json` and all numbered snapshots as one schema package.\nNever requery a logical table already present in that package, and never\nlaunch concurrent schema queries.\n\nIdentifier lists and schema snapshots are working files. Keep them until\nverification finishes, then delete them in Phase 7.\n\n### 3.2 Analyze every call and consumer\n\nFor every source inventory row:\n\n1. Read the complete enclosing function or template block.\n2. Trace imported wrappers, URL variables, query builders, body builders,\n   response mappers, types, components, templates, and every caller.\n3. Follow conditional branches, spreads, dynamic arrays, and runtime\n   configuration.\n4. Map the entity set to its logical table using the schema package.\n5. Apply every rule in\n   [references\u002Fcolumn-analysis.md](references\u002Fcolumn-analysis.md).\n6. Record requirements per owning logical table, not merely per request.\n7. Classify the row as `mapped`, `non-table`, or `not-a-call`.\n8. Leave the row unresolved if any runtime branch or consumer remains unknown.\n\nOne logical table is normally reached from several places. Collect every call\nsite for a table before proposing its fields: duplicated or competing\nwrappers, per-page scripts, different query shapes, and repeated calls in the\nsame file. A later call site for an already-analyzed table can still add\ncolumns, so never stop at the first one.\n\nFor normal record GETs without `$select`, derive output fields from every\nconsumer and propose a source edit adding the smallest explicit projection.\nFilters, ordering, and other query fields still belong in the fields setting,\neven when they should not be added to the output projection.\n\nKeep the response projection and fields-setting allowlist as separate sets.\nNever add a filter-only, order-only, grouping-only, or write-only column to an\nexisting `$select` unless a response consumer also reads it.\n\n### 3.3 Build configuration proposals\n\nFor each wildcard setting:\n\n1. Union the proven requirements from every call site that reaches that\n   logical table within the applicable site behavior.\n2. Validate each proposed name against the schema package.\n3. Link every proposed column to source path and line or a user-confirmed\n   external contract.\n4. Produce the exact replacement:\n\n   ```text\n   Webapi\u002F\u003Ctable>\u002Ffields = \u003Ccolumn-name-1>,\u003Ccolumn-name-2>,\u003Ccolumn-name-3>\n   ```\n\n5. Keep the proposal unresolved if it is empty or any evidence is incomplete.\n\nFor each already-explicit setting:\n\n- compare configured columns with proven required columns;\n- classify it as exact, missing required columns, potentially overbroad, or\n  externally justified;\n- include an exact proposed fix for every gap;\n- do not silently change it.\n\nUpdate the report. Resolve all wildcard and call-site rows before continuing.\n\n**Output:** Evidence-complete report with exact wildcard replacements and all\nalready-explicit configurations.\n\n## Phase 4: Review the complete plan\n\n**Goal:** Present the full exposure reduction before edits.\n\nShow:\n\n- wildcard issues found and the exact replacement for each;\n- evidence for every proposed column;\n- source GETs requiring `$select`;\n- already-explicit settings and any missing or excess columns;\n- any missing or duplicate settings found during inventory;\n- zero unresolved call sites.\n\n\u003C!-- gate: migrate-webapi-selectall:4.apply-plan | category=consent | cancel-leaves=reviewed-migration-report -->\n\n> ? **Gate (consent · migrate-webapi-selectall:4.apply-plan):** Approve all wildcard replacements, required source projections, optional explicit-setting hardening, and local edits. Canceling preserves only the report.\n\nUse `AskUserQuestion` with:\n\n- `Apply all wildcard fixes and approved explicit fixes`;\n- `Apply all wildcard fixes only`;\n- `Cancel`.\n\nNever offer a subset of wildcard fixes.\n\n## Phase 5: Apply approved edits\n\n**Goal:** Update source projections and every wildcard setting.\n\n1. Use `Edit` to add approved `$select` projections. Preserve methods, filters,\n   ordering, expansion, pagination, encoding, Liquid expressions, and error\n   handling.\n2. Use `Edit` to replace every wildcard value in every scope and profile.\n   Preserve identifiers, key names, quoting, indentation, comments, and\n   unrelated values.\n3. Apply already-explicit changes only when included in the selected approval.\n4. Re-read every changed block immediately and update report status.\n\nIf any edit fails or a file changed since review, stop. Do not continue with a\npartial configuration set and do not perform a broad rollback over user work.\n\n**Output:** All approved local edits and updated report.\n\n## Phase 6: Verify independently\n\n**Goal:** Prove the migration without trusting prior notes.\n\n1. Repeat Phase 2 discovery from scratch.\n2. Confirm every configuration scope contains zero\n   `Webapi\u002F\u003Ctable>\u002Ffields` wildcard values.\n3. Compare each migrated value with its approved exact replacement.\n4. Reopen every call site and replay the coverage analysis:\n   - mapped table and method remain correct;\n   - required setting columns are present;\n   - normal record GETs use explicit `$select`;\n   - expanded, lookup, write, FetchXML, file, and image columns remain covered.\n5. Run the existing project build for SPA sites. For non-SPA sites,\n   inspect edited JavaScript and Liquid syntax and use existing site tests when\n   available.\n6. Finalize the report status and every entry status, then delete the previous\n   `migration-report.html` and re-render it from the updated data file.\n\nDo not claim full hardening while explicit configuration gaps remain. Use the\npartial status defined in the reporting contract when applicable.\n\n**Output:** Final report and verified local migration.\n\n### Final site-integrity gate\n\nAfter all approved source edits, independent verification, and the SPA build\nare complete, run:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fvalidate-site-integrity.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nFix every blocking error before claiming the migration is complete or offering\ndeployment. Inspect and report review findings in both directions and with\nexpanded content. Rerun this gate after any later source change.\n\n## Phase 7: Deploy and summarize\n\n**Goal:** Publish only verified changes.\n\nRe-confirm every identity detail in\n[references\u002Fsite-transfer.md](references\u002Fsite-transfer.md) with the user\nimmediately before uploading, and display the exact command. Select the\ndeployment profile the user reviewed, and use `default` only when they name\nit. Any change of environment, website, data model, or profile requires a\nseparate deployment approval.\n\n\u003C!-- gate: migrate-webapi-selectall:7.deploy | category=final | cancel-leaves=local-migration -->\n\n> ? **Gate (final · migrate-webapi-selectall:7.deploy):** Approve the verified migration for the displayed environment, website, site type, data model, and deployment profile. Canceling preserves local edits and the final report without changing the live site.\n\nUse `AskUserQuestion`: `Deploy now` or `Keep local only`.\n\n- Re-run `pac auth who` and `pac env who`, and stop on any mismatch.\n  `pac pages upload-code-site` accepts no `--environment` and targets whatever\n  the active authentication profile reports.\n- For SPA sites, confirm `.powerpages-site` contains the approved\n  configuration edits, run the existing production build, then run\n  `pac pages upload-code-site --rootPath \"\u003CPROJECT_ROOT>\" --siteName\n  \"\u003CSITE_NAME>\"`.\n- For non-SPA sites, run `pac pages upload --path \"\u003CPROJECT_ROOT>\"\n  --environment \"\u003CENVIRONMENT>\" --modelVersion \"\u003CStandard|Enhanced>\"\n  --deploymentProfile \"\u003CPROFILE>\"`.\n\nNever substitute one upload command for the other. Each corrupts the other\nsite type, and the damage cannot be reverted.\n\nAfter deployment, list the read paths a smoke test would exercise: GET calls,\n`$select` projections, `$expand`, FetchXML, and aggregates. Never run one\nunprompted.\n\n\u003C!-- gate: migrate-webapi-selectall:7.smoke-test | category=progress | cancel-leaves=deployed-migration-unverified -->\n\n> ? **Gate (progress · migrate-webapi-selectall:7.smoke-test):** Approve the listed read-path smoke test against the deployed site. Canceling skips it and reports the deployed migration as unverified.\n\nUse `AskUserQuestion`: `Run the read-path smoke test` or `Skip verification`.\n\nNever issue write, file, or image requests. Ask the user to exercise those\npaths themselves against disposable records.\n\nTreat HTTP 403 responses as evidence to investigate and never restore `*`. Do\nnot add a column under the prior approval. Return to Phase 3, update the exact\nplan and report, repeat the Phase 4 approval, independently verify in Phase 6,\nand obtain a new Phase 7 deployment approval.\n\nDelete every working file created during the migration, keeping only\n`docs\u002Fwebapi-selectall-migration\u002Fmigration-report.html` and the\n`power-pages-icon.png` the renderer places beside it:\n\n- `table-identifiers.txt` and `table-identifiers-pass-\u003CN>.txt`;\n- `table-schema.json` and `table-schema.pass-\u003CN>.json`;\n- `migration-report.json`.\n\nDelete only files this migration created, and confirm the directory holds the\nreport and its icon alone. Skip cleanup while returning to an earlier phase,\nand delete the regenerated files once that pass finishes.\n\nRecord usage by following\n`${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md` with\n`--skillName \"MigrateWebapiSelectall\"`.\n\nSummarize wildcard counts, explicit reviews, source edits, report path,\nverification, deployment, and every path left unverified.\n\n## Progress tracking\n\nCreate these tasks before Phase 1:\n\n| Task subject | activeForm | Description |\n|---|---|---|\n| Prepare migration project | Preparing migration project | Confirm the site, then resolve layouts and git state |\n| Inventory Web API usage | Inventorying Web API usage | Find every configuration and source call |\n| Resolve actual columns | Resolving actual columns | Retrieve schema and trace every consumer |\n| Review migration plan | Reviewing migration plan | Present exact fixes and evidence |\n| Apply approved migration | Applying approved migration | Edit projections and configurations |\n| Verify migration results | Verifying migration results | Repeat discovery, build, and finalize report |\n| Deploy and summarize | Deploying and summarizing | Publish after approval and report outcome |\n\nMark each task `in_progress` when starting and `completed` when finished.\n\n---\n\n**Begin with Phase 1: Prepare.**\n",{"name":5,"model":53,"description":7,"allowed-tools":54,"argument-hint":55,"user-invocable":56},"opus","Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, TaskCreate, TaskUpdate, TaskList","Optional Power Pages project path",true,"main","0a55a88fa2855404029d1e5450faf92878baf763","plugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall",230,"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 02:26:14",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":56},[69,72,75],{"tool":70,"command":71},"npx","npx skills add microsoft\u002Fpower-platform-skills --skill migrate-webapi-selectall",{"tool":73,"command":74},"bunx","bunx skills add microsoft\u002Fpower-platform-skills --skill migrate-webapi-selectall",{"tool":76,"command":77},"pnpm","pnpm dlx skills add microsoft\u002Fpower-platform-skills --skill migrate-webapi-selectall","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002FSKILL.md",[80,86,92,96,100,106,110],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"assets\u002Fmigration-report-template.html","ASSET","资产文件",17861,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Fassets\u002Fmigration-report-template.html",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fcolumn-analysis.md","REFERENCE","参考文档",4856,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Freferences\u002Fcolumn-analysis.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fconfiguration-and-reporting.md",6132,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Freferences\u002Fconfiguration-and-reporting.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fsite-transfer.md",3678,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Freferences\u002Fsite-transfer.md",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"scoring.py","SCRIPT","脚本",22872,"https:\u002F\u002Fgithub.com\u002FNakul-Kumar\u002FAgentDevOps\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fn8n-research\u002Fscoring.py",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Fquery-table-schema.js",15348,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Fscripts\u002Fquery-table-schema.js",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"scripts\u002Frender-migration-report.js",2279,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fmigrate-webapi-selectall\u002Fscripts\u002Frender-migration-report.js",[115,135,158,176,190,200],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":48},"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",[],[117,34,122,123,124,125,126,127,128,129,130,131,132,133,134,36],"when","connection","error","sign","intelligence","configuration","use","process","diagnostics","environment","authentication","cloud","recovery",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":146,"publishedAt":48},"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",[141],{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[147,148,149,150,151,129,128,152,153,126,154,155,156,122,157],"report issue","report","issue","support","user","bug","summary","draft","operation","for","bug-report",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":164,"publishedAt":48},"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",[],[129,165,166,167,122,168,169,170,171,34,172,128,173,174,175],"investigate","investigate process","mining","process mining","investigation","perspectives","question","business","pattern","across","analytical",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":48},"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",[],[183,184,34,128,185,186,187,188,189,122],"metric","derive metric","formula","missing","reuse","saved","custom",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":48},"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",[],[197,198,122,128,129,199,34],"compare","compare cohorts","results",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":48},"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",[],[207,208,209,168,122,167,210,211,128,129,34,212,213],"analyze","variants","analyze variants","case","paths","work","common"]