[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699SGHYNG0WNMP0HQ2F2PZJ":3,"skill-same:01M699SGHYNG0WNMP0HQ2F2PZJ":101},{"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":28,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":84},"01M699SGHYNG0WNMP0HQ2F2PZJ","analyze-performance",null,"Statically scans the entire local Power Pages codebase for performance anti-patterns — unpaginated Power Pages lists, webpages\u002Fweb templates used as custom data APIs, FetchXML over-fetching \u002F N+1 \u002F advanced query hints \u002F cache bypassing, unbounded Web API queries, disabled header\u002Ffooter output caching, sign-in and page tracking, main-thread-blocking JS, CSS @import, frequent Web API polling, and oversized assets — then enriches findings with AI-driven suggestions and mitigations grounded in the affected customer-code snippets, reports them, and offers safe auto-fixes with per-fix approval. Use when the user wants to: \"check performance\", \"perf check\", \"find performance issues\", \"why is my site slow\", \"optimize my Power Pages site\", \"find anti-patterns\", \"review FetchXML performance\", \"is my site over-fetching data\", or \"audit site performance\".","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\u002Fanalyze-performance\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,9,48,49,50,51,52,53],"performance","analyze performance","analyze","affected","MCP","opus","web api","as","local","power","auto","anti-patterns","fix","edit","write","read","why","search","power pages","web","customer","safe","css","docs","review","2026-11-10 10:12:30",false,"---\nname: analyze-performance\ndescription: >-\n  Statically scans the entire local Power Pages codebase for performance\n  anti-patterns — unpaginated Power Pages lists, webpages\u002Fweb templates used as\n  custom data APIs, FetchXML over-fetching \u002F N+1 \u002F advanced query hints \u002F cache\n  bypassing, unbounded Web API queries, disabled header\u002Ffooter output caching,\n  sign-in and page tracking, main-thread-blocking JS, CSS @import, frequent Web\n  API polling, and oversized assets — then enriches findings with AI-driven\n  suggestions and mitigations grounded in the affected customer-code snippets,\n  reports them, and offers safe auto-fixes with per-fix approval.\n  Use when the user wants to: \"check performance\", \"perf check\", \"find\n  performance issues\", \"why is my site slow\", \"optimize my Power Pages site\",\n  \"find anti-patterns\", \"review FetchXML performance\", \"is my site over-fetching\n  data\", or \"audit site performance\".\nuser-invocable: true\nargument-hint: \"[optional: --review \u003Cout-dir>]\"\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_search, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_fetch\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# analyze-performance\n\nStatically analyzes the **entire local Power Pages codebase** for known performance anti-patterns, enriches the static findings with **AI-driven, code-aware suggestions and mitigations**, presents them by severity in an HTML report + plain-language summary, and offers **safe auto-fixes with per-fix approval**. Never applies a fix without explicit consent.\n\nThis skill reads local source only — it does not call the deployed site. For a live security\u002Fvulnerability scan use `\u002Fscan-site`.\n\n**Initial request:** $ARGUMENTS\n\n## Prerequisites\n\n- An existing local **non-SPA** Power Pages project or PAC CLI site download.\n  `.powerpages-site\u002F`, root-level `.portalconfig\u002F`, `website.yml`, and portal\n  content folders are useful discovery markers, but they are not all required\n  when the user supplies an existing site folder.\n- SPA websites are not supported yet. `powerpages.config.json` is the\n  authoritative local SPA marker; if it exists at the selected project root,\n  tell the user this skill currently supports non-SPA websites only and stop.\n- Node.js (bundled scripts run under `node`).\n\nNo sign-in, PAC CLI, or Azure CLI is required — the analysis is fully offline.\n\n## What it detects\n\nSee `references\u002Fperformance-reference.md` for the authoritative rule catalog (tags,\nseverities, detection, fixes, thresholds, and Microsoft Learn sources). The scan\nmust cover all of these categories:\n\n- **List pagination** — Power Pages list definitions with no positive\n  `adx_pagesize` \u002F `pagesize`.\n- **Webpages used as APIs** — FetchXML\u002Fentity-backed web templates or webpage\n  content that emit JSON\u002FXML instead of a normal HTML page.\n- **FetchXML anti-patterns** — `all-attributes`, no explicit columns, too many\n  columns, no paging, oversized `count`\u002F`top`, N+1 queries inside Liquid loops,\n  unnecessary `returntotalrecordcount`, leading-wildcard `like` filters, and\n  related-table ordering.\n- **FetchXML query controls** — advanced query hints (`options`,\n  `latematerialize`, `no-lock`, `useraworderby`, filter `hint`) and request-time\n  values or explicit settings that bypass server-side query caching.\n- **Web API anti-patterns** — `$select=*`, missing `$select`, no page bound\n  (`$top` safety cap or `Prefer: odata.maxpagesize=N` cursor paging),\n  too many selected columns, oversized `$top`, `$count=true`, `$expand` without\n  a nested `$select`, `contains`\u002F`endswith` filters, request-time date filters,\n  related-table ordering, request-per-item\u002FN+1 loops, and short-interval polling.\n- **Rendering and caching** — disabled Header\u002FFooter output caching,\n  render-blocking `\u003Chead>` scripts, runtime CSS `@import`, synchronous XHR\u002FjQuery,\n  and `document.write`.\n- **Tracking and volume** — sign-in\u002Fpage\u002Ffile tracking, excessive web-file or\n  web-role counts, and oversized static assets.\n\n## Phases\n\n1. **Prerequisites** — locate the project, confirm the site exists, detect review mode\n1.5. **Ground in current performance guidance** — optional Microsoft Learn cross-check (capped, offline-safe)\n2. **Scan** — run the deterministic analyzer over the codebase\n2.5. **AI mitigation pass** — inspect customer-code snippets behind each finding and add code-aware suggestions\u002Fmitigations\n3. **Present findings** — severity table + coverage stats + AI suggestions\n4. **Offer auto-fixes** — per-finding consent loop for the safely-automatable findings\n5. **Verify** — re-run the analyzer to confirm fixes resolved their findings\n6. **Report & next action** — render the HTML report, summarize, and route follow-ups\n\n## Task Tracking\n\nCreate tasks in three groups. Mark each `in_progress` when starting, `completed` when done.\n\n| Group | When to create | Tasks |\n|-------|----------------|-------|\n| 1 | At start | Verify prerequisites and locate project |\n| 2 | After prerequisites pass | Scan codebase for anti-patterns · Add AI-driven suggestions and mitigations · Present findings |\n| 3 | After findings presented (skip all three in review mode) | Offer auto-fixes (only if any `autoFixAvailable`) · Verify fixes · Render report and route follow-ups |\n\n---\n\n## Phase 1 — Verify Prerequisites and Locate Project\n\n1. **Detect review mode first**: if `$ARGUMENTS` contains `--review \u003Cout-dir>`,\n   remember `\u003CREVIEW_DIR>`.\n2. Resolve `\u003CPROJECT_ROOT>` in this order:\n   - If `\u003CREVIEW_DIR>` itself contains recognizable Power Pages source, use it as\n     both `\u003CPROJECT_ROOT>` and `\u003CREVIEW_DIR>`. This supports orchestrated reviews\n     that pass the downloaded site folder directly.\n   - Otherwise use an explicitly supplied project directory, then the current\n     working directory. Use `Glob` to locate `**\u002Fpowerpages.config.json`,\n     `**\u002F.powerpages-site`, `**\u002F.portalconfig`, or `**\u002Fwebsite.yml` when needed.\n3. Treat any of these as recognizable Power Pages source:\n   `.powerpages-site\u002F`, root-level `.portalconfig\u002F`, `website.yml`, or a\n   characteristic portal export layout containing folders such as `web-pages\u002F`,\n   `web-templates\u002F`, or `web-files\u002F`. Do **not** reject an explicitly supplied\n   existing site folder merely because it lacks `.powerpages-site\u002F`.\n4. If `\u003CPROJECT_ROOT>\u002Fpowerpages.config.json` exists, tell the user that the\n   selected path is a SPA website and this skill currently supports non-SPA\n   Power Pages websites only, then **stop**.\n5. If no existing directory with recognizable non-SPA Power Pages source can be located,\n   tell the user and recommend `\u002Fcreate-site`, then **stop**.\n6. In review mode Phases 3, 4, and 6-presentation are skipped: Phase 2 runs,\n   Step 6.2 writes JSON only, and the skill stops after writing it.\n\nReport: \"Found project: `\u003CPROJECT_ROOT>`. Scanning for performance anti-patterns.\"\n\n## Phase 1.5 — Ground in current performance guidance\n\n> Skip in **review mode**. Cap this step at ~30 seconds. If MCP search \u002F fetch errors out or is unavailable, log a one-line note and continue — this skill must remain runnable offline.\n\n1. Run `microsoft_docs_search` with the query: `Power Pages Site Checker performance FetchXML output caching best practices`.\n2. Optionally `microsoft_docs_fetch` `https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fpower-pages\u002Fadmin\u002Fsite-checker-performance`.\n3. Extract a one-paragraph summary of what Microsoft Learn currently says. Compare it against the rule catalog in `references\u002Fperformance-reference.md`. If Learn documents a performance pattern not covered by any analyzer rule, surface it to the user in Phase 6 as a **manual** follow-up — do not silently invent findings the analyzer did not produce.\n\n## Phase 2 — Scan the codebase\n\nRun the deterministic analyzer over the whole project:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fanalyze-performance.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nThe analyzer prints a single JSON object `{ status, findings, details, severityCounts }` to stdout. Parse it. Each finding has `id`, `tag`, `severity`, `title`, `location`, `details`, `fix`, `autoFixAvailable`, and (when auto-fixable) `fixAction`. See `references\u002Fperformance-reference.md` for the finding envelope and every tag's meaning.\n\nIf the only finding is `PERF-NONE`, the codebase is clean — note this and skip Phase 4\u002F5 (still render the report in Phase 6 so the user has a record).\n\n## Phase 2.5 — Add AI-driven suggestions and mitigations\n\nRun this after every deterministic scan result that will be presented or written\nto `analyze-performance.json` (including **review mode**). Skip only `PERF-NONE`.\n\nFor each finding, inspect the relevant customer-code context before writing the\nfinal JSON:\n\n1. Read the file named by `finding.location` and capture a tight snippet around\n   the line (about 20 lines before\u002Fafter, capped so the report stays readable).\n   If the file no longer exists or the finding has no location, use the finding's\n   `details` and `fix` only.\n2. Add these fields to the finding object:\n   - `aiSuggestion`: one or two sentences explaining the best next change for\n     this specific code path, grounded in the snippet and the rule catalog.\n   - `mitigation`: a concrete mitigation plan that preserves behavior. Name the\n     likely code\u002Fconfig edit, the safer alternative when there are tradeoffs, and\n     anything the user must verify manually.\n3. Keep the deterministic fields (`tag`, `severity`, `fix`, `fixAction`,\n   `autoFixAvailable`) unchanged. Do **not** downgrade, suppress, or invent\n   analyzer findings during this AI pass.\n4. For heuristic findings (for example webpage-as-API, Web API N+1, cache\n   bypassing, related-column ordering), say that the suggestion is conditional\n   and name the observation that would confirm it.\n5. For auto-fixable site-setting\u002Ftracking findings, keep `mitigation` aligned\n   with the existing `fixAction` and repeat any important caveat, especially the\n   Header\u002FFooter output-cache substitution requirement.\n\nThe report renderer displays `aiSuggestion` and `mitigation` as separate fields,\nso write them into the JSON rather than only mentioning them in chat. If the\ncurrent AI context cannot safely inspect a file because it is restricted or too\nlarge, add a conservative mitigation based on `details`\u002F`fix` and explicitly say\nthe source snippet was not inspected.\n\n## Phase 3 — Present findings\n\n> Skip in **review mode** (go straight to Step 5.1's JSON write).\n\nPresent all findings grouped by severity, highest first. Include the AI\nsuggestion and mitigation under each row (or immediately after the table for long\nitems) so the user sees both the static check and the code-aware recommendation:\n\n| # | Severity | Tag | Issue | Location | Auto-fix? |\n|---|----------|-----|-------|----------|-----------|\n| 1 | high | PERF-FETCHXML-ALLATTR | FetchXML retrieves all attributes | `...:2` | No |\n| 2 | warning | PERF-HEADER-OUTPUTCACHE | Header output caching disabled | `...sitesetting.yml` | Yes |\n\nThen show the coverage stats from `details.entries` (FetchXML\u002FLiquid, list,\nWeb API\u002Fscript and CSS files scanned; web-file\u002Fweb-role counts; total findings).\nKeep the language plain; explain a tag only when asked. Make clear that AI\nsuggestions are grounded in the local snippet but still require developer\njudgment for business-specific behavior.\n\n## Phase 4 — Offer auto-fixes\n\n> Skip in **review mode**. Skip entirely if no finding has `autoFixAvailable: true`.\n\nOnly the site-setting and tracking findings are safely automatable (`PERF-HEADER-OUTPUTCACHE`, `PERF-FOOTER-OUTPUTCACHE`, `PERF-SIGNIN-TRACKING`, `PERF-WEBPAGE-TRACKING`, `PERF-WEBFILE-TRACKING`). List pagination, webpage-as-API, FetchXML, Web API, query-hint, cache-bypass, and asset findings require human judgment — present those as manual fixes only.\n\nFor each finding with `autoFixAvailable: true`, in order:\n\n\u003C!-- gate: analyze-performance:4.auto-fix | category=consent | cancel-leaves=nothing -->\n> ? **Gate (consent · analyze-performance:4.auto-fix):** Per-finding consent before applying any auto-fix. **Loops once per `autoFixAvailable` finding** — each gets its own Yes \u002F No \u002F Skip-all `AskUserQuestion` naming the finding's tag and the exact change. **Never batch fixes** — three fixable findings = three separate prompts (unless the user picks \"Skip all\", which short-circuits the loop). Each fix has its own blast radius (a different site setting or YAML file), so approving one does not approve the next.\n>\n> **Trigger:** Phase 4, once per fixable finding.\n> **Why we ask:** Enabling output caching alone can break header\u002Ffooter rendering unless the web templates also use `{% substitution %}` (see caveat below); toggling tracking edits committed YAML. The user must consent to each concrete change.\n> **Cancel leaves:** Nothing — declining a fix leaves that finding untouched and reported as manual.\n\nFor the approved finding, apply its `fixAction`:\n\n- **`create-site-setting`** (setting is absent from a per-record `.powerpages-site`\n  layout): create it with the shared helper —\n  ```bash\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Fcreate-site-setting.js\" --projectRoot \"\u003CPROJECT_ROOT>\" --name \"\u003CfixAction.name>\" --value \"\u003CfixAction.value>\" --type boolean --description \"\u003Cshort why>\"\n  ```\n  If it reports the setting already exists, treat it as already handled and switch to the `set-site-setting` path.\n- **`set-site-setting`** (setting exists but is wrong): use `Edit` on the finding's `location` file to flip the `value:` line (`false` → `true`, or tracking `true` → `false`). Do **not** call `create-site-setting.js` — it refuses to overwrite.\n- **`set-yaml-field`**: use `Edit` at the finding's precise `location` to set\n  `\u003CfixAction.field>: \u003CfixAction.value>` (e.g., `adx_enabletracking: false`).\n  For a non-SPA aggregate `sitesetting.yml`, `fixAction.recordName` identifies the\n  setting record and the location points at its exact `adx_value` line. Do not\n  replace another record's matching boolean.\n\n> **Output-cache caveat (always surface this):** enabling `Header\u002FFooter\u002FOutputCache\u002FEnabled` is **not** sufficient on its own — the Header, Footer, and Languages-Dropdown web templates must also use the `{% substitution %}` Liquid tag, or those regions stop rendering. After applying an output-cache fix, tell the user to update those templates and verify the site still renders.\n\nMark each finding **Fixed**, **Skipped**, or **Manual required** as you go.\n\n## Phase 5 — Verify fixes\n\n> Skip in **review mode**. Skip if no auto-fix was applied.\n\nRe-run the analyzer to confirm the applied fixes resolved their findings:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fanalyze-performance.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nConfirm each fixed finding's tag\u002Flocation is gone (or downgraded from `warning` to `info` for the absent→present caching case). If a fix did not take, report it and offer to retry or hand it to the user. Use this re-scanned result set as the basis for the Phase 6 report so it reflects the post-fix state.\n\n## Phase 6 — Report & next action\n\n### 6.1 Review mode short-circuit\n\nHandled at Step 6.2 below — review mode never reaches the HTML render or the follow-up walk-through.\n\n### Step 6.2 — Write the review JSON\n\nWrite the enriched `{ status, findings, details }` object (the Phase 5 re-scan result if a re-scan ran, otherwise the Phase 2 result, with Phase 2.5 `aiSuggestion`\u002F`mitigation` fields applied) to a JSON file:\n\n- **Review mode**: write to `\u003CREVIEW_DIR>\u002Fanalyze-performance.json`, then **stop**. The orchestrating skill (e.g., `security-review`) handles presentation.\n- **Interactive mode**: write to `\u003CTEMP_DIR>\u002Fanalyze-performance.json` where `\u003CTEMP_DIR>` is a scratch directory containing only this file.\n\nThe filename **must** be `analyze-performance.json` — that is the key\n`build-review-data.js` maps to the Performance section.\n\n### Step 6.3 — Render the HTML report\n\nSkip in **review mode**. Reuse the shared report pipeline (same template as the security review and site scan):\n\nThe final HTML report is a persistent website artifact under\n`\u003CPROJECT_ROOT>\u002Fdocs\u002F`, consistent with the other review reports. Only\n`analyze-performance.json` and `data.json` are temporary scratch files; delete their\ntemporary directory after the HTML render succeeds.\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fbuild-review-data.js\" \\\n  --reportName \"Performance Analysis\" \\\n  --inputDir \"\u003CTEMP_DIR>\" \\\n  --siteName \"\u003CSITE_NAME>\" \\\n  --goalLabel \"Performance\" \\\n  --scopeLabel \"Local codebase\" \\\n  --summary \"\u003CSUMMARY_TEXT>\" \\\n  --output \"\u003CTEMP_DIR>\u002Fdata.json\"\n\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Frender-review.js\" \\\n  --data \"\u003CTEMP_DIR>\u002Fdata.json\" \\\n  --output \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fperformance-analysis-\u003CYYYY-MM-DD-HHMMSS>.html\"\n\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fvalidate-analyze-performance.js\" \\\n  --reportPath \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fperformance-analysis-\u003CYYYY-MM-DD-HHMMSS>.html\"\n```\n\n`\u003CSITE_NAME>` comes from the site's `website.yml`; fall back to the folder name.\nThe filename **must** include the local timestamp (e.g.,\n`performance-analysis-2026-05-14-053805.html`). Delete `\u003CTEMP_DIR>` after the\nrender and explicit validation succeed, then open the report in the browser.\n\n### Step 6.4 — Summarize and route follow-ups\n\n\u003C!-- gate: analyze-performance:6.next-action | category=plan | cancel-leaves=nothing -->\n> ? **Gate (plan · analyze-performance:6.next-action):** After the report, recommend the single most useful next step and let the user accept or choose differently via `AskUserQuestion` — walk through the manual (non-auto-fixable) findings one at a time, re-scan, or finish. Reviewing findings and re-scanning are read-only; nothing is changed without a later Phase 4 consent.\n>\n> **Trigger:** Phase 6, after the report is rendered (interactive mode only).\n> **Why we ask:** The manual list, webpage-as-API, FetchXML, Web API, query-hint,\n> cache-bypass, and asset fixes need edits the user must drive; auto-walking every\n> finding would be noisy if they only wanted the report.\n> **Cancel leaves:** Nothing — the report is already written; declining ends the skill cleanly.\n\nGive a plain-language summary: total findings, count by severity, and how many\nwere auto-fixed. For manual findings (list pagination, webpage-as-API patterns,\nFetchXML\u002FWeb API anti-patterns, query hints, cache bypassing, volume counts, and\nlarge assets), offer to walk through them one at a time with the concrete edit\neach needs. If nothing meaningful remains, end the skill — do not ask just to ask.\n\n### Record Skill Usage\n\n> Reference: `${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md`\n>\n> Use `--skillName \"AnalyzePerformance\"`.\n\n## Constraints\n\n- **Read-only until consent.** The analyzer never mutates anything. The only writes are the HTML report, the scratch JSON, and auto-fixes the user explicitly approves in Phase 4.\n- **High-signal findings.** Heuristics (Web API N+1, missing-but-defaultable caching) are intentionally conservative to avoid false positives. When a finding is a heuristic, say so.\n- **Plain language.** Explain a tag only when asked; lead with the impact, not the internal name.\n- **Offline-safe.** Phase 1.5 is best-effort; the skill must complete with no network access.\n\n## References\n\n- `references\u002Fperformance-reference.md` — authoritative rule catalog: tags, severities, detection logic, fixes, auto-fix actions, thresholds, manual-only checks, key nuances, and Microsoft Learn sources. Read when explaining a finding or deciding whether a fix is safe.\n\n## Progress Tracking Table\n\n| Task subject | activeForm | Description |\n|---|---|---|\n| Verify prerequisites and locate project | Verifying prerequisites | Locate an explicit\u002Fcurrent code-site or PAC-download folder, confirm recognizable Power Pages source, detect review mode |\n| Scan codebase for anti-patterns | Scanning codebase | Run analyze-performance.js over the project, parse findings JSON |\n| Present findings | Presenting findings | Show severity table and coverage stats |\n| Offer auto-fixes | Applying auto-fixes | Per-finding consent loop; apply site-setting\u002Ftracking fixes, surface substitution caveat |\n| Verify fixes | Verifying fixes | Re-run analyzer, confirm fixed findings are gone |\n| Render report and route follow-ups | Rendering report | Build review JSON, render HTML, summarize, route manual follow-ups |\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# analyze-performance\n\nStatically analyzes the **entire local Power Pages codebase** for known performance anti-patterns, enriches the static findings with **AI-driven, code-aware suggestions and mitigations**, presents them by severity in an HTML report + plain-language summary, and offers **safe auto-fixes with per-fix approval**. Never applies a fix without explicit consent.\n\nThis skill reads local source only — it does not call the deployed site. For a live security\u002Fvulnerability scan use `\u002Fscan-site`.\n\n**Initial request:** $ARGUMENTS\n\n## Prerequisites\n\n- An existing local **non-SPA** Power Pages project or PAC CLI site download.\n  `.powerpages-site\u002F`, root-level `.portalconfig\u002F`, `website.yml`, and portal\n  content folders are useful discovery markers, but they are not all required\n  when the user supplies an existing site folder.\n- SPA websites are not supported yet. `powerpages.config.json` is the\n  authoritative local SPA marker; if it exists at the selected project root,\n  tell the user this skill currently supports non-SPA websites only and stop.\n- Node.js (bundled scripts run under `node`).\n\nNo sign-in, PAC CLI, or Azure CLI is required — the analysis is fully offline.\n\n## What it detects\n\nSee `references\u002Fperformance-reference.md` for the authoritative rule catalog (tags,\nseverities, detection, fixes, thresholds, and Microsoft Learn sources). The scan\nmust cover all of these categories:\n\n- **List pagination** — Power Pages list definitions with no positive\n  `adx_pagesize` \u002F `pagesize`.\n- **Webpages used as APIs** — FetchXML\u002Fentity-backed web templates or webpage\n  content that emit JSON\u002FXML instead of a normal HTML page.\n- **FetchXML anti-patterns** — `all-attributes`, no explicit columns, too many\n  columns, no paging, oversized `count`\u002F`top`, N+1 queries inside Liquid loops,\n  unnecessary `returntotalrecordcount`, leading-wildcard `like` filters, and\n  related-table ordering.\n- **FetchXML query controls** — advanced query hints (`options`,\n  `latematerialize`, `no-lock`, `useraworderby`, filter `hint`) and request-time\n  values or explicit settings that bypass server-side query caching.\n- **Web API anti-patterns** — `$select=*`, missing `$select`, no page bound\n  (`$top` safety cap or `Prefer: odata.maxpagesize=N` cursor paging),\n  too many selected columns, oversized `$top`, `$count=true`, `$expand` without\n  a nested `$select`, `contains`\u002F`endswith` filters, request-time date filters,\n  related-table ordering, request-per-item\u002FN+1 loops, and short-interval polling.\n- **Rendering and caching** — disabled Header\u002FFooter output caching,\n  render-blocking `\u003Chead>` scripts, runtime CSS `@import`, synchronous XHR\u002FjQuery,\n  and `document.write`.\n- **Tracking and volume** — sign-in\u002Fpage\u002Ffile tracking, excessive web-file or\n  web-role counts, and oversized static assets.\n\n## Phases\n\n1. **Prerequisites** — locate the project, confirm the site exists, detect review mode\n1.5. **Ground in current performance guidance** — optional Microsoft Learn cross-check (capped, offline-safe)\n2. **Scan** — run the deterministic analyzer over the codebase\n2.5. **AI mitigation pass** — inspect customer-code snippets behind each finding and add code-aware suggestions\u002Fmitigations\n3. **Present findings** — severity table + coverage stats + AI suggestions\n4. **Offer auto-fixes** — per-finding consent loop for the safely-automatable findings\n5. **Verify** — re-run the analyzer to confirm fixes resolved their findings\n6. **Report & next action** — render the HTML report, summarize, and route follow-ups\n\n## Task Tracking\n\nCreate tasks in three groups. Mark each `in_progress` when starting, `completed` when done.\n\n| Group | When to create | Tasks |\n|-------|----------------|-------|\n| 1 | At start | Verify prerequisites and locate project |\n| 2 | After prerequisites pass | Scan codebase for anti-patterns · Add AI-driven suggestions and mitigations · Present findings |\n| 3 | After findings presented (skip all three in review mode) | Offer auto-fixes (only if any `autoFixAvailable`) · Verify fixes · Render report and route follow-ups |\n\n---\n\n## Phase 1 — Verify Prerequisites and Locate Project\n\n1. **Detect review mode first**: if `$ARGUMENTS` contains `--review \u003Cout-dir>`,\n   remember `\u003CREVIEW_DIR>`.\n2. Resolve `\u003CPROJECT_ROOT>` in this order:\n   - If `\u003CREVIEW_DIR>` itself contains recognizable Power Pages source, use it as\n     both `\u003CPROJECT_ROOT>` and `\u003CREVIEW_DIR>`. This supports orchestrated reviews\n     that pass the downloaded site folder directly.\n   - Otherwise use an explicitly supplied project directory, then the current\n     working directory. Use `Glob` to locate `**\u002Fpowerpages.config.json`,\n     `**\u002F.powerpages-site`, `**\u002F.portalconfig`, or `**\u002Fwebsite.yml` when needed.\n3. Treat any of these as recognizable Power Pages source:\n   `.powerpages-site\u002F`, root-level `.portalconfig\u002F`, `website.yml`, or a\n   characteristic portal export layout containing folders such as `web-pages\u002F`,\n   `web-templates\u002F`, or `web-files\u002F`. Do **not** reject an explicitly supplied\n   existing site folder merely because it lacks `.powerpages-site\u002F`.\n4. If `\u003CPROJECT_ROOT>\u002Fpowerpages.config.json` exists, tell the user that the\n   selected path is a SPA website and this skill currently supports non-SPA\n   Power Pages websites only, then **stop**.\n5. If no existing directory with recognizable non-SPA Power Pages source can be located,\n   tell the user and recommend `\u002Fcreate-site`, then **stop**.\n6. In review mode Phases 3, 4, and 6-presentation are skipped: Phase 2 runs,\n   Step 6.2 writes JSON only, and the skill stops after writing it.\n\nReport: \"Found project: `\u003CPROJECT_ROOT>`. Scanning for performance anti-patterns.\"\n\n## Phase 1.5 — Ground in current performance guidance\n\n> Skip in **review mode**. Cap this step at ~30 seconds. If MCP search \u002F fetch errors out or is unavailable, log a one-line note and continue — this skill must remain runnable offline.\n\n1. Run `microsoft_docs_search` with the query: `Power Pages Site Checker performance FetchXML output caching best practices`.\n2. Optionally `microsoft_docs_fetch` `https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fpower-pages\u002Fadmin\u002Fsite-checker-performance`.\n3. Extract a one-paragraph summary of what Microsoft Learn currently says. Compare it against the rule catalog in `references\u002Fperformance-reference.md`. If Learn documents a performance pattern not covered by any analyzer rule, surface it to the user in Phase 6 as a **manual** follow-up — do not silently invent findings the analyzer did not produce.\n\n## Phase 2 — Scan the codebase\n\nRun the deterministic analyzer over the whole project:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fanalyze-performance.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nThe analyzer prints a single JSON object `{ status, findings, details, severityCounts }` to stdout. Parse it. Each finding has `id`, `tag`, `severity`, `title`, `location`, `details`, `fix`, `autoFixAvailable`, and (when auto-fixable) `fixAction`. See `references\u002Fperformance-reference.md` for the finding envelope and every tag's meaning.\n\nIf the only finding is `PERF-NONE`, the codebase is clean — note this and skip Phase 4\u002F5 (still render the report in Phase 6 so the user has a record).\n\n## Phase 2.5 — Add AI-driven suggestions and mitigations\n\nRun this after every deterministic scan result that will be presented or written\nto `analyze-performance.json` (including **review mode**). Skip only `PERF-NONE`.\n\nFor each finding, inspect the relevant customer-code context before writing the\nfinal JSON:\n\n1. Read the file named by `finding.location` and capture a tight snippet around\n   the line (about 20 lines before\u002Fafter, capped so the report stays readable).\n   If the file no longer exists or the finding has no location, use the finding's\n   `details` and `fix` only.\n2. Add these fields to the finding object:\n   - `aiSuggestion`: one or two sentences explaining the best next change for\n     this specific code path, grounded in the snippet and the rule catalog.\n   - `mitigation`: a concrete mitigation plan that preserves behavior. Name the\n     likely code\u002Fconfig edit, the safer alternative when there are tradeoffs, and\n     anything the user must verify manually.\n3. Keep the deterministic fields (`tag`, `severity`, `fix`, `fixAction`,\n   `autoFixAvailable`) unchanged. Do **not** downgrade, suppress, or invent\n   analyzer findings during this AI pass.\n4. For heuristic findings (for example webpage-as-API, Web API N+1, cache\n   bypassing, related-column ordering), say that the suggestion is conditional\n   and name the observation that would confirm it.\n5. For auto-fixable site-setting\u002Ftracking findings, keep `mitigation` aligned\n   with the existing `fixAction` and repeat any important caveat, especially the\n   Header\u002FFooter output-cache substitution requirement.\n\nThe report renderer displays `aiSuggestion` and `mitigation` as separate fields,\nso write them into the JSON rather than only mentioning them in chat. If the\ncurrent AI context cannot safely inspect a file because it is restricted or too\nlarge, add a conservative mitigation based on `details`\u002F`fix` and explicitly say\nthe source snippet was not inspected.\n\n## Phase 3 — Present findings\n\n> Skip in **review mode** (go straight to Step 5.1's JSON write).\n\nPresent all findings grouped by severity, highest first. Include the AI\nsuggestion and mitigation under each row (or immediately after the table for long\nitems) so the user sees both the static check and the code-aware recommendation:\n\n| # | Severity | Tag | Issue | Location | Auto-fix? |\n|---|----------|-----|-------|----------|-----------|\n| 1 | high | PERF-FETCHXML-ALLATTR | FetchXML retrieves all attributes | `...:2` | No |\n| 2 | warning | PERF-HEADER-OUTPUTCACHE | Header output caching disabled | `...sitesetting.yml` | Yes |\n\nThen show the coverage stats from `details.entries` (FetchXML\u002FLiquid, list,\nWeb API\u002Fscript and CSS files scanned; web-file\u002Fweb-role counts; total findings).\nKeep the language plain; explain a tag only when asked. Make clear that AI\nsuggestions are grounded in the local snippet but still require developer\njudgment for business-specific behavior.\n\n## Phase 4 — Offer auto-fixes\n\n> Skip in **review mode**. Skip entirely if no finding has `autoFixAvailable: true`.\n\nOnly the site-setting and tracking findings are safely automatable (`PERF-HEADER-OUTPUTCACHE`, `PERF-FOOTER-OUTPUTCACHE`, `PERF-SIGNIN-TRACKING`, `PERF-WEBPAGE-TRACKING`, `PERF-WEBFILE-TRACKING`). List pagination, webpage-as-API, FetchXML, Web API, query-hint, cache-bypass, and asset findings require human judgment — present those as manual fixes only.\n\nFor each finding with `autoFixAvailable: true`, in order:\n\n\u003C!-- gate: analyze-performance:4.auto-fix | category=consent | cancel-leaves=nothing -->\n> ? **Gate (consent · analyze-performance:4.auto-fix):** Per-finding consent before applying any auto-fix. **Loops once per `autoFixAvailable` finding** — each gets its own Yes \u002F No \u002F Skip-all `AskUserQuestion` naming the finding's tag and the exact change. **Never batch fixes** — three fixable findings = three separate prompts (unless the user picks \"Skip all\", which short-circuits the loop). Each fix has its own blast radius (a different site setting or YAML file), so approving one does not approve the next.\n>\n> **Trigger:** Phase 4, once per fixable finding.\n> **Why we ask:** Enabling output caching alone can break header\u002Ffooter rendering unless the web templates also use `{% substitution %}` (see caveat below); toggling tracking edits committed YAML. The user must consent to each concrete change.\n> **Cancel leaves:** Nothing — declining a fix leaves that finding untouched and reported as manual.\n\nFor the approved finding, apply its `fixAction`:\n\n- **`create-site-setting`** (setting is absent from a per-record `.powerpages-site`\n  layout): create it with the shared helper —\n  ```bash\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Fcreate-site-setting.js\" --projectRoot \"\u003CPROJECT_ROOT>\" --name \"\u003CfixAction.name>\" --value \"\u003CfixAction.value>\" --type boolean --description \"\u003Cshort why>\"\n  ```\n  If it reports the setting already exists, treat it as already handled and switch to the `set-site-setting` path.\n- **`set-site-setting`** (setting exists but is wrong): use `Edit` on the finding's `location` file to flip the `value:` line (`false` → `true`, or tracking `true` → `false`). Do **not** call `create-site-setting.js` — it refuses to overwrite.\n- **`set-yaml-field`**: use `Edit` at the finding's precise `location` to set\n  `\u003CfixAction.field>: \u003CfixAction.value>` (e.g., `adx_enabletracking: false`).\n  For a non-SPA aggregate `sitesetting.yml`, `fixAction.recordName` identifies the\n  setting record and the location points at its exact `adx_value` line. Do not\n  replace another record's matching boolean.\n\n> **Output-cache caveat (always surface this):** enabling `Header\u002FFooter\u002FOutputCache\u002FEnabled` is **not** sufficient on its own — the Header, Footer, and Languages-Dropdown web templates must also use the `{% substitution %}` Liquid tag, or those regions stop rendering. After applying an output-cache fix, tell the user to update those templates and verify the site still renders.\n\nMark each finding **Fixed**, **Skipped**, or **Manual required** as you go.\n\n## Phase 5 — Verify fixes\n\n> Skip in **review mode**. Skip if no auto-fix was applied.\n\nRe-run the analyzer to confirm the applied fixes resolved their findings:\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fanalyze-performance.js\" --projectRoot \"\u003CPROJECT_ROOT>\"\n```\n\nConfirm each fixed finding's tag\u002Flocation is gone (or downgraded from `warning` to `info` for the absent→present caching case). If a fix did not take, report it and offer to retry or hand it to the user. Use this re-scanned result set as the basis for the Phase 6 report so it reflects the post-fix state.\n\n## Phase 6 — Report & next action\n\n### 6.1 Review mode short-circuit\n\nHandled at Step 6.2 below — review mode never reaches the HTML render or the follow-up walk-through.\n\n### Step 6.2 — Write the review JSON\n\nWrite the enriched `{ status, findings, details }` object (the Phase 5 re-scan result if a re-scan ran, otherwise the Phase 2 result, with Phase 2.5 `aiSuggestion`\u002F`mitigation` fields applied) to a JSON file:\n\n- **Review mode**: write to `\u003CREVIEW_DIR>\u002Fanalyze-performance.json`, then **stop**. The orchestrating skill (e.g., `security-review`) handles presentation.\n- **Interactive mode**: write to `\u003CTEMP_DIR>\u002Fanalyze-performance.json` where `\u003CTEMP_DIR>` is a scratch directory containing only this file.\n\nThe filename **must** be `analyze-performance.json` — that is the key\n`build-review-data.js` maps to the Performance section.\n\n### Step 6.3 — Render the HTML report\n\nSkip in **review mode**. Reuse the shared report pipeline (same template as the security review and site scan):\n\nThe final HTML report is a persistent website artifact under\n`\u003CPROJECT_ROOT>\u002Fdocs\u002F`, consistent with the other review reports. Only\n`analyze-performance.json` and `data.json` are temporary scratch files; delete their\ntemporary directory after the HTML render succeeds.\n\n```bash\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fbuild-review-data.js\" \\\n  --reportName \"Performance Analysis\" \\\n  --inputDir \"\u003CTEMP_DIR>\" \\\n  --siteName \"\u003CSITE_NAME>\" \\\n  --goalLabel \"Performance\" \\\n  --scopeLabel \"Local codebase\" \\\n  --summary \"\u003CSUMMARY_TEXT>\" \\\n  --output \"\u003CTEMP_DIR>\u002Fdata.json\"\n\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Frender-review.js\" \\\n  --data \"\u003CTEMP_DIR>\u002Fdata.json\" \\\n  --output \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fperformance-analysis-\u003CYYYY-MM-DD-HHMMSS>.html\"\n\nnode \"${PLUGIN_ROOT}\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fvalidate-analyze-performance.js\" \\\n  --reportPath \"\u003CPROJECT_ROOT>\u002Fdocs\u002Fperformance-analysis-\u003CYYYY-MM-DD-HHMMSS>.html\"\n```\n\n`\u003CSITE_NAME>` comes from the site's `website.yml`; fall back to the folder name.\nThe filename **must** include the local timestamp (e.g.,\n`performance-analysis-2026-05-14-053805.html`). Delete `\u003CTEMP_DIR>` after the\nrender and explicit validation succeed, then open the report in the browser.\n\n### Step 6.4 — Summarize and route follow-ups\n\n\u003C!-- gate: analyze-performance:6.next-action | category=plan | cancel-leaves=nothing -->\n> ? **Gate (plan · analyze-performance:6.next-action):** After the report, recommend the single most useful next step and let the user accept or choose differently via `AskUserQuestion` — walk through the manual (non-auto-fixable) findings one at a time, re-scan, or finish. Reviewing findings and re-scanning are read-only; nothing is changed without a later Phase 4 consent.\n>\n> **Trigger:** Phase 6, after the report is rendered (interactive mode only).\n> **Why we ask:** The manual list, webpage-as-API, FetchXML, Web API, query-hint,\n> cache-bypass, and asset fixes need edits the user must drive; auto-walking every\n> finding would be noisy if they only wanted the report.\n> **Cancel leaves:** Nothing — the report is already written; declining ends the skill cleanly.\n\nGive a plain-language summary: total findings, count by severity, and how many\nwere auto-fixed. For manual findings (list pagination, webpage-as-API patterns,\nFetchXML\u002FWeb API anti-patterns, query hints, cache bypassing, volume counts, and\nlarge assets), offer to walk through them one at a time with the concrete edit\neach needs. If nothing meaningful remains, end the skill — do not ask just to ask.\n\n### Record Skill Usage\n\n> Reference: `${PLUGIN_ROOT}\u002Freferences\u002Fskill-tracking-reference.md`\n>\n> Use `--skillName \"AnalyzePerformance\"`.\n\n## Constraints\n\n- **Read-only until consent.** The analyzer never mutates anything. The only writes are the HTML report, the scratch JSON, and auto-fixes the user explicitly approves in Phase 4.\n- **High-signal findings.** Heuristics (Web API N+1, missing-but-defaultable caching) are intentionally conservative to avoid false positives. When a finding is a heuristic, say so.\n- **Plain language.** Explain a tag only when asked; lead with the impact, not the internal name.\n- **Offline-safe.** Phase 1.5 is best-effort; the skill must complete with no network access.\n\n## References\n\n- `references\u002Fperformance-reference.md` — authoritative rule catalog: tags, severities, detection logic, fixes, auto-fix actions, thresholds, manual-only checks, key nuances, and Microsoft Learn sources. Read when explaining a finding or deciding whether a fix is safe.\n\n## Progress Tracking Table\n\n| Task subject | activeForm | Description |\n|---|---|---|\n| Verify prerequisites and locate project | Verifying prerequisites | Locate an explicit\u002Fcurrent code-site or PAC-download folder, confirm recognizable Power Pages source, detect review mode |\n| Scan codebase for anti-patterns | Scanning codebase | Run analyze-performance.js over the project, parse findings JSON |\n| Present findings | Presenting findings | Show severity table and coverage stats |\n| Offer auto-fixes | Applying auto-fixes | Per-finding consent loop; apply site-setting\u002Ftracking fixes, surface substitution caveat |\n| Verify fixes | Verifying fixes | Re-run analyzer, confirm fixed findings are gone |\n| Render report and route follow-ups | Rendering report | Build review JSON, render HTML, summarize, route manual follow-ups |\n",{"name":5,"model":34,"description":7,"allowed-tools":59,"argument-hint":60,"user-invocable":61},"Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, TaskCreate, TaskUpdate, TaskList, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_search, mcp__plugin_power-pages_microsoft-learn__microsoft_docs_fetch","[optional: --review \u003Cout-dir>]",true,"main","0a55a88fa2855404029d1e5450faf92878baf763","plugins\u002Fpower-pages\u002Fskills\u002Fanalyze-performance",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":73,"prompt":83,"zipAvailable":61},[74,77,80],{"tool":75,"command":76},"npx","npx skills add microsoft\u002Fpower-platform-skills --skill analyze-performance",{"tool":78,"command":79},"bunx","bunx skills add microsoft\u002Fpower-platform-skills --skill analyze-performance",{"tool":81,"command":82},"pnpm","pnpm dlx skills add microsoft\u002Fpower-platform-skills --skill analyze-performance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fanalyze-performance\u002FSKILL.md",[85,91,97],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fperformance-reference.md","REFERENCE","参考文档",23366,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fanalyze-performance\u002Freferences\u002Fperformance-reference.md",{"path":92,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":95,"sourceHtmlUrl":96},"scripts\u002Fanalyze-performance.js","SCRIPT","脚本",69124,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fanalyze-performance.js",{"path":98,"resourceType":93,"resourceTypeDesc":94,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fvalidate-analyze-performance.js",2575,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpower-pages\u002Fskills\u002Fanalyze-performance\u002Fscripts\u002Fvalidate-analyze-performance.js",[102,123,144,162,176,186],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":54},"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",[],[104,44,109,110,111,112,113,114,115,116,117,118,119,120,121,122],"when","connection","error","sign","intelligence","configuration","use","process","diagnostics","environment","authentication","cloud","recovery","Bash",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":132,"publishedAt":54},"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",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",[133,134,135,136,137,116,115,138,139,113,140,141,142,109,143],"report issue","report","issue","support","user","bug","summary","draft","operation","for","bug-report",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":54},"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",[],[116,151,152,153,109,154,155,156,157,44,158,115,159,160,161],"investigate","investigate process","mining","process mining","investigation","perspectives","question","business","pattern","across","analytical",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":54},"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",[],[169,170,44,115,171,172,173,174,175,109],"metric","derive metric","formula","missing","reuse","saved","custom",{"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":54},"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",[],[183,184,109,115,116,185,44],"compare","compare cohorts","results",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":54},"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",[],[31,193,194,154,109,153,195,196,115,116,44,197,198],"variants","analyze variants","case","paths","work","common"]