[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M711HY4ERDCZSSXMQ5VT3X17":3,"skill-same:01M711HY4ERDCZSSXMQ5VT3X17":79},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":72},"01M711HY4ERDCZSSXMQ5VT3X17","infopath-to-canvas",null,"Migrate a Microsoft InfoPath form (.xsn) to a Power Apps Canvas app. USE WHEN the user wants to convert, port, or migrate an InfoPath form\u002Ftemplate to Canvas Apps, or asks for help moving off of InfoPath.","microsoft\u002Fpower-cat-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M711HNR06SENTW4XRAD4QG81",70,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002FPower Platform Migration Factory\u002Finfopath-to-canvas\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,9],"infopath to canvas","canvas","use","when","for","true","port","form","apps","app","power","template","convert","migrate","Bash","powershell","help","canvas app","power apps","2026-11-10 10:12:30",false,"---\nname: infopath-to-canvas\nversion: 2.2.0\ndescription: Migrate a Microsoft InfoPath form (.xsn) to a Power Apps Canvas app. USE WHEN the user wants to convert, port, or migrate an InfoPath form\u002Ftemplate to Canvas Apps, or asks for help moving off of InfoPath.\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, PowerShell, Agent, TaskCreate, TaskUpdate, TaskList, Skill, EnterPlanMode, ExitPlanMode\n---\n\n# Migrate an InfoPath Form to a Canvas App\n\nMigrate the InfoPath form described below:\n\n$ARGUMENTS\n\nA `.xsn` is a CAB archive containing `manifest.xsf` (rules, views, data connections),\n`schema*.xsd` (data schema), `template.xml` (defaults), and XSL views. This skill runs six\nphases: **extract → inventory → verify → hand off to `\u002Fcanvas-app` → configure environment\nvariables (optional) → export migration log**. Pause for user approval after the inventory and\nagain after verification.\n\n> **v2.0 changes:** the downstream `generate-canvas-app` skill this migration used to hand\n> off to has been folded into the unified `\u002Fcanvas-app` skill (which now auto-detects create\n> vs. edit) in the `canvas-apps@power-platform-skills` plugin. This skill's Phase 0 prerequisite\n> check and Phase 4 handoff have been updated to match. A new **Phase 3 — Verify** step has also\n> been added: XSLT-view extraction alone is not reliable enough to generate from directly.\n>\n> **v2.1 changes:** added **Phase 5 — Environment Variables**, so a migrated app's data-source\n> connections move with it across dev\u002Ftest\u002Fprod instead of being hardcoded to whatever\n> environment it was built against, and **Phase 6 — Export Migration Log**, which writes a\n> dated record of everything this skill did for a given `.xsn` so the run is auditable and\n> repeatable later.\n>\n> **v2.2 changes:** two refinements based on running this at factory scale. **Phase 5 —\n> Environment Variables is now optional**, gated on whether the migration is actually going to\n> move across environments (ALM dev\u002Ftest\u002Fprod) — a POC or single-environment migration can skip\n> it and bind data sources directly. **Phase 3 — Verify no longer requires screenshots** to\n> proceed; they're the preferred, highest-confidence check when available, but the skill now\n> falls back to a documented lower-confidence pass over the XSLT-derived inventory and flags\n> exactly which fields\u002Fsections\u002Frules weren't screenshot-confirmed, so a batch of migrations\n> isn't blocked waiting on screenshots for every form.\n\n---\n\n## Phase 0 — Prerequisites\n\n[#phase-0--prerequisites](#phase-0--prerequisites)\n\nBefore extracting anything, confirm the environment is ready:\n\n1. **Plugins installed.** This skill depends on `canvas-apps@power-platform-skills` for the\n   actual app generation. If `mcp__canvas-authoring__*` tools aren't available, tell the user to run:\n   ```\n   \u002Fplugin marketplace add microsoft\u002Fpower-platform-skills\n   \u002Fplugin install canvas-apps@power-platform-skills\n   \u002Fplugin marketplace add microsoft\u002Fpower-cat-skills\n   \u002Fplugin install powercat-canvas-apps@power-cat-skills\n   ```\n2. **Coauthoring session connected.** The Canvas Authoring MCP server needs an active session\n   before Phase 3 can hand off successfully. If the user already knows they want to wire this\n   to a real Canvas app (not just mock with collections), have them run `\u002Fconfigure-canvas-mcp`\n   (or describe the flow: open the target app in Power Apps Studio, enable Settings → Updates →\n   Coauthoring, copy the Studio URL, keep the tab open) **before** Phase 1 finishes, so the\n   SharePoint-list diff in Phase 1 has something to diff against. If they only want to mock data\n   for now, this can wait until they're ready to build for real.\n\n---\n\n## Phase 1 — Extract\n\n[#phase-1--extract](#phase-1--extract)\n\nFrom `$ARGUMENTS`, resolve a `.xsn` path. If the user gave a folder, `Glob` for `*.xsn` inside; ask if there are multiple or none.\n\nIf a sibling `xsn_extracted\u002F` already contains `manifest.xsf`, reuse it. Otherwise extract to `\u003Csource_dir>\u002Fxsn_extracted\u002F`:\n\n- **Windows**: `& \"$env:SystemRoot\\System32\\expand.exe\" \"\u003Cform>.xsn\" -F:* \"\u003Cxsn_extracted>\"` via PowerShell\n- **macOS \u002F Linux**: `cabextract -d \u003Cxsn_extracted> \u003Cform>.xsn`\n\nVerify `manifest.xsf` and `schema1.xsd` exist; abort if not.\n\n---\n\n## Phase 2 — Inventory\n\n[#phase-2--inventory](#phase-2--inventory)\n\nSpawn a general-purpose `Agent` to write `infopath-inventory.md` covering:\n\n- **Fields** — from `schema1.xsd` + `template.xml` `dfs:dataFields`: decoded name, type\n(Text, Date, Number, Choice, multi-Choice, Person, NoteEnhanced\u002Frich-text, Lookup, …),\nconstraints (`maxLength`, `pattern`, `enumeration`, `minOccurs`\u002F`nillable`), default.\nDecode URL-encoded names: `_x0020_`=space, `_x0028_`=`(`, `_x0029_`=`)`, `_x002d_`=`-`,\n`_x0023_`=`#`, `_x0026_`=`&`.\n- **Rules** — from `manifest.xsf`: schema-required fields, `xsf:errorCondition` (field +\nXPath translated to plain English + message), `xsf:ruleSet`\u002F`xsf:domEventHandler` (trigger,\ncondition, action), `xsf:submit` destination.\n- **Routing \u002F state fields** — flag any field that drives multi-stage approval or workflow\nrouting (a \"status,\" \"stage,\" or \"current approver\" field referenced across several views'\nvisibility rules). Multi-stage approval forms are common in this migration set — call out the\nfull stage sequence (who approves after whom) as its own subsection, since it becomes the\nCanvas app's state machine.\n- **Lookup connections** — every non-`schema*.xsd` schema: source name + columns used.\n- **Views** — section headings and field ordering from the XSL views; note multiple views and,\nfor routed forms, which view\u002Fsection is visible at which stage.\n- **Section recommendation** — propose logical sections of 10–30 fields each for Canvas.\n\nAfter the agent returns, surface counts (fields \u002F rules \u002F connections \u002F sections \u002F stages) and continue to Phase 3 — don't ask the mock-vs-real or aesthetic questions yet; those come after verification, once the inventory is known to be accurate.\n\n---\n\n## Phase 3 — Verify\n\n[#phase-3--verify](#phase-3--verify)\n\n**XSLT-derived views are frequently wrong in specific, non-obvious ways** — a section heading\ngets misread as a field, a field is missed entirely because it's conditionally rendered, or a\nlabel doesn't match the underlying field name (e.g. a \"Trade Volume\" label over an\n`ExpectedVolume` field). Do not treat the Phase 2 inventory as final.\n\n1. Ask the user for InfoPath Designer screenshots of each view (or ask them to open the form\n   in InfoPath\u002FInfoPath Filler and screenshot each screen\u002Fstage). This is the single most\n   effective accuracy check available and is **preferred** — prioritize getting real\n   screenshots over re-parsing the XSLT more carefully.\n2. **If screenshots are provided**, cross-check every field, section header, and approval-role\n   label in the inventory against them. Correct mismatches directly in\n   `infopath-inventory.md` and note what changed (e.g. \"Team\" was a section header, not a\n   field; found an undocumented field the XSLT extraction missed; two similarly-named approval\n   roles are actually distinct fields). Mark the inventory **screenshot-verified**.\n3. **If screenshots aren't available or practical** (e.g. running this across a large batch of\n   forms), don't block on them. Instead:\n   - Re-check the Phase 2 inventory against the raw XSLT views a second time, specifically\n     hunting for the failure modes above (misread section headings, conditionally-rendered\n     fields, label\u002Ffield-name mismatches).\n   - Mark the inventory **XSLT-only, not screenshot-verified**, and add a \"Needs manual\n     verification\" subsection to `infopath-inventory.md` listing every field, section, and\n     rule where confidence is low (ambiguous labels, deeply nested conditional visibility,\n     anything the XSLT structure made a judgment call on).\n   - Carry this confidence flag forward into `canvas-app-prompt.md` (Phase 4) and the\n     migration log (Phase 6), so it's visible to whoever reviews or accepts the generated app,\n     and so the form can be prioritized for a screenshot pass later if one becomes available.\n4. Only after this pass, ask the user:\n   1. Mock with collections in `App.OnStart` (default), or wire to real SharePoint?\n   2. Keep all sections, or drop any?\n   3. Aesthetic preferences? (default: clean professional)\n   4. Is this migration expected to move across environments (dev\u002Ftest\u002Fprod ALM), or is it a\n      one-off \u002F single-environment build (e.g. a POC)? This decides whether Phase 5\n      (Environment Variables) runs.\n\nWait for answers.\n\n**If the user wants to wire to real SharePoint**, and they haven't already connected a\ncoauthoring session (Phase 0), do it now — Canvas can't bind to a connection that doesn't\nexist in the app. Tell them the steps (Power Apps Studio → Data → Add data → SharePoint → pick\nsite\u002Flist) and that this skill can verify the schema once it's done.\n\nWhen they confirm, call `mcp__canvas-authoring__connect` if no session is active yet, then\n`mcp__canvas-authoring__list_data_sources` to see what's connected, then\n`mcp__canvas-authoring__get_data_source_schema` for each list. Diff against the verified\ninventory: every InfoPath field should map to a SharePoint column of compatible type. Report\nany **missing columns**, **type mismatches** (e.g. InfoPath Date vs. SP Text), or\n**extra-required columns** the form doesn't populate. Pause and let the user reconcile\n(rename columns, add missing ones, or trim the inventory) before Phase 4.\n\n---\n\n## Phase 4 — Hand off to `\u002Fcanvas-app`\n\n[#phase-4--hand-off-to-canvas-app](#phase-4--hand-off-to-canvas-app)\n\nWrite `canvas-app-prompt.md` containing:\n\n- The kept sections + field lists with type hints (call out dates, multi-choice, rich text).\n- Each InfoPath rule restated as the desired Canvas behavior in plain English (the `\u002Fcanvas-app`\n  skill's discovery\u002Fdesign agents map this to Power Fx).\n- The routing\u002Fstate-machine sequence from Phase 2, restated as a screen-visibility or\n  status-gated navigation plan (e.g. \"Screen X is only reachable when Status = 'Pending Local\n  Ops Review'\"), since Canvas has no native equivalent of InfoPath's per-view `xsf` rules.\n- Mock-data plan if mocking: 3–5 sample records per section, plus choice-list collections\nseeded from enumerations \u002F lookup tables.\n- The user's aesthetic answer.\n- Validation should **block** submit (`DisplayMode.Disabled` on Save buttons) — an intentional\nupgrade from InfoPath's flag-but-don't-block behavior; flag this as a deliberate change.\n\nThen invoke `\u002Fcanvas-app` via the `Skill` tool, passing `canvas-app-prompt.md` as the\ngeneration requirements (`\u002Fcanvas-app` auto-detects create-vs-edit from the current app state,\nruns its own discovery phase against `list_controls` \u002F `list_apis` \u002F `list_data_sources`,\nproduces an app plan for approval, then fans out `canvas-screen-editor` builder agents per\nscreen in parallel and validates the result with `compile_canvas`). If `\u002Fcanvas-app` isn't\navailable, instruct the user to install `canvas-apps@power-platform-skills` (see Phase 0) and\nthen run `\u002Fcanvas-app` against `canvas-app-prompt.md` directly.\n\n---\n\n## Phase 5 — Environment Variables (Optional)\n\n[#phase-5--environment-variables-optional](#phase-5--environment-variables-optional)\n\nThis phase is **optional** and only runs if the user indicated in Phase 3 that this migration\nwill move across environments (dev\u002Ftest\u002Fprod ALM) rather than staying a one-off or\nsingle-environment build.\n\n- **If the migration is a POC \u002F single-environment build**: skip this phase. Bind the app's\n  data sources directly (real connection or mocked collections, per the Phase 3 answer) and\n  say plainly in the migration log (Phase 6) that environment variables were skipped and why,\n  so it's an explicit, visible decision rather than a silent gap — not a blocker to revisit\n  unless the app later needs to be promoted across environments.\n- **If the migration is expected to move across environments**, proceed as follows. Once the\n  app is wired to real data sources (or is about to be — this is easiest to set up right after\n  `\u002Fcanvas-app` creates the data-source connections), do **not** leave the SharePoint site URL,\n  list name\u002FGUID, environment ID, or any other connection detail hardcoded into the `.pa.yaml`.\n  Hardcoded values tie the generated app to whichever environment it happened to be built\n  against and break the moment it's promoted from dev to test to prod.\n\n  1. For each data source identified in Phase 3's diff, define a Dataverse **environment\n     variable** per connection detail that changes across environments (typically: site URL,\n     list name, and — if the app calls a Flow\u002Fconnector — the connection reference). Use clear,\n     consistent naming, e.g. `envvar_ClientBespokeProcess_SiteUrl`,\n     `envvar_ClientBespokeProcess_ListName`.\n  2. Reference the environment variable's current value in the app's `App.OnStart` (or\n     wherever the data source is bound) instead of a literal string — e.g.\n     `SharePointSiteUrl: Environment.EnvironmentVariable(\"envvar_ClientBespokeProcess_SiteUrl\")`\n     — rather than the raw URL.\n  3. Record each environment variable's schema name, purpose, and per-environment values\n     (dev\u002Ftest\u002Fprod) in `canvas-app-prompt.md` (or a companion `environment-variables.md`) so\n     they can be set as part of solution deployment rather than rediscovered later.\n  4. If the target environment doesn't yet have Dataverse environment variables\n     enabled\u002Favailable, flag this to the user before proceeding — don't silently fall back to\n     hardcoded values.\n\n---\n\n## Phase 6 — Export Migration Log\n\n[#phase-6--export-migration-log](#phase-6--export-migration-log)\n\nEvery time this skill is run against a particular `.xsn`, write (or update, on a re-run)\n`\u003Cform-name>-migration-log.md` alongside the extracted form, dated at the top. Capture:\n\n- Source `.xsn` path\u002Fname and extraction date.\n- Inventory summary (field \u002F rule \u002F connection \u002F section \u002F stage counts from Phase 2).\n- Phase 3 verification method and confidence: whether the inventory is\n  **screenshot-verified** or **XSLT-only**, every correction made if screenshots were used\n  (what the screenshots caught that the XSLT extraction got wrong), and — if screenshots\n  weren't available — the full \"Needs manual verification\" list carried over from\n  `infopath-inventory.md`, so future re-runs, audits, or a later screenshot pass don't have to\n  rediscover which areas are still unconfirmed.\n- The decisions captured before handoff: mock vs. real SharePoint, sections kept\u002Fdropped,\n  aesthetic direction, and whether this migration is ALM (dev\u002Ftest\u002Fprod) or single-environment.\n- Phase 5 outcome: either the environment variables defined and what they point to, or an\n  explicit note that Phase 5 was skipped (single-environment\u002FPOC) and why.\n- The outcome of the `\u002Fcanvas-app` handoff: app name\u002Flocation, whether `compile_canvas`\n  passed cleanly or needed fixes, and any deliberate behavior changes from InfoPath (e.g. the\n  block-on-submit validation change).\n\nThis log is the artifact to hand to a customer or reviewer as evidence of what changed and\nwhy — write it in plain language, not as a raw dump of the phase outputs.\n","# Migrate an InfoPath Form to a Canvas App\n\nMigrate the InfoPath form described below:\n\n$ARGUMENTS\n\nA `.xsn` is a CAB archive containing `manifest.xsf` (rules, views, data connections),\n`schema*.xsd` (data schema), `template.xml` (defaults), and XSL views. This skill runs six\nphases: **extract → inventory → verify → hand off to `\u002Fcanvas-app` → configure environment\nvariables (optional) → export migration log**. Pause for user approval after the inventory and\nagain after verification.\n\n> **v2.0 changes:** the downstream `generate-canvas-app` skill this migration used to hand\n> off to has been folded into the unified `\u002Fcanvas-app` skill (which now auto-detects create\n> vs. edit) in the `canvas-apps@power-platform-skills` plugin. This skill's Phase 0 prerequisite\n> check and Phase 4 handoff have been updated to match. A new **Phase 3 — Verify** step has also\n> been added: XSLT-view extraction alone is not reliable enough to generate from directly.\n>\n> **v2.1 changes:** added **Phase 5 — Environment Variables**, so a migrated app's data-source\n> connections move with it across dev\u002Ftest\u002Fprod instead of being hardcoded to whatever\n> environment it was built against, and **Phase 6 — Export Migration Log**, which writes a\n> dated record of everything this skill did for a given `.xsn` so the run is auditable and\n> repeatable later.\n>\n> **v2.2 changes:** two refinements based on running this at factory scale. **Phase 5 —\n> Environment Variables is now optional**, gated on whether the migration is actually going to\n> move across environments (ALM dev\u002Ftest\u002Fprod) — a POC or single-environment migration can skip\n> it and bind data sources directly. **Phase 3 — Verify no longer requires screenshots** to\n> proceed; they're the preferred, highest-confidence check when available, but the skill now\n> falls back to a documented lower-confidence pass over the XSLT-derived inventory and flags\n> exactly which fields\u002Fsections\u002Frules weren't screenshot-confirmed, so a batch of migrations\n> isn't blocked waiting on screenshots for every form.\n\n---\n\n## Phase 0 — Prerequisites\n\n[#phase-0--prerequisites](#phase-0--prerequisites)\n\nBefore extracting anything, confirm the environment is ready:\n\n1. **Plugins installed.** This skill depends on `canvas-apps@power-platform-skills` for the\n   actual app generation. If `mcp__canvas-authoring__*` tools aren't available, tell the user to run:\n   ```\n   \u002Fplugin marketplace add microsoft\u002Fpower-platform-skills\n   \u002Fplugin install canvas-apps@power-platform-skills\n   \u002Fplugin marketplace add microsoft\u002Fpower-cat-skills\n   \u002Fplugin install powercat-canvas-apps@power-cat-skills\n   ```\n2. **Coauthoring session connected.** The Canvas Authoring MCP server needs an active session\n   before Phase 3 can hand off successfully. If the user already knows they want to wire this\n   to a real Canvas app (not just mock with collections), have them run `\u002Fconfigure-canvas-mcp`\n   (or describe the flow: open the target app in Power Apps Studio, enable Settings → Updates →\n   Coauthoring, copy the Studio URL, keep the tab open) **before** Phase 1 finishes, so the\n   SharePoint-list diff in Phase 1 has something to diff against. If they only want to mock data\n   for now, this can wait until they're ready to build for real.\n\n---\n\n## Phase 1 — Extract\n\n[#phase-1--extract](#phase-1--extract)\n\nFrom `$ARGUMENTS`, resolve a `.xsn` path. If the user gave a folder, `Glob` for `*.xsn` inside; ask if there are multiple or none.\n\nIf a sibling `xsn_extracted\u002F` already contains `manifest.xsf`, reuse it. Otherwise extract to `\u003Csource_dir>\u002Fxsn_extracted\u002F`:\n\n- **Windows**: `& \"$env:SystemRoot\\System32\\expand.exe\" \"\u003Cform>.xsn\" -F:* \"\u003Cxsn_extracted>\"` via PowerShell\n- **macOS \u002F Linux**: `cabextract -d \u003Cxsn_extracted> \u003Cform>.xsn`\n\nVerify `manifest.xsf` and `schema1.xsd` exist; abort if not.\n\n---\n\n## Phase 2 — Inventory\n\n[#phase-2--inventory](#phase-2--inventory)\n\nSpawn a general-purpose `Agent` to write `infopath-inventory.md` covering:\n\n- **Fields** — from `schema1.xsd` + `template.xml` `dfs:dataFields`: decoded name, type\n(Text, Date, Number, Choice, multi-Choice, Person, NoteEnhanced\u002Frich-text, Lookup, …),\nconstraints (`maxLength`, `pattern`, `enumeration`, `minOccurs`\u002F`nillable`), default.\nDecode URL-encoded names: `_x0020_`=space, `_x0028_`=`(`, `_x0029_`=`)`, `_x002d_`=`-`,\n`_x0023_`=`#`, `_x0026_`=`&`.\n- **Rules** — from `manifest.xsf`: schema-required fields, `xsf:errorCondition` (field +\nXPath translated to plain English + message), `xsf:ruleSet`\u002F`xsf:domEventHandler` (trigger,\ncondition, action), `xsf:submit` destination.\n- **Routing \u002F state fields** — flag any field that drives multi-stage approval or workflow\nrouting (a \"status,\" \"stage,\" or \"current approver\" field referenced across several views'\nvisibility rules). Multi-stage approval forms are common in this migration set — call out the\nfull stage sequence (who approves after whom) as its own subsection, since it becomes the\nCanvas app's state machine.\n- **Lookup connections** — every non-`schema*.xsd` schema: source name + columns used.\n- **Views** — section headings and field ordering from the XSL views; note multiple views and,\nfor routed forms, which view\u002Fsection is visible at which stage.\n- **Section recommendation** — propose logical sections of 10–30 fields each for Canvas.\n\nAfter the agent returns, surface counts (fields \u002F rules \u002F connections \u002F sections \u002F stages) and continue to Phase 3 — don't ask the mock-vs-real or aesthetic questions yet; those come after verification, once the inventory is known to be accurate.\n\n---\n\n## Phase 3 — Verify\n\n[#phase-3--verify](#phase-3--verify)\n\n**XSLT-derived views are frequently wrong in specific, non-obvious ways** — a section heading\ngets misread as a field, a field is missed entirely because it's conditionally rendered, or a\nlabel doesn't match the underlying field name (e.g. a \"Trade Volume\" label over an\n`ExpectedVolume` field). Do not treat the Phase 2 inventory as final.\n\n1. Ask the user for InfoPath Designer screenshots of each view (or ask them to open the form\n   in InfoPath\u002FInfoPath Filler and screenshot each screen\u002Fstage). This is the single most\n   effective accuracy check available and is **preferred** — prioritize getting real\n   screenshots over re-parsing the XSLT more carefully.\n2. **If screenshots are provided**, cross-check every field, section header, and approval-role\n   label in the inventory against them. Correct mismatches directly in\n   `infopath-inventory.md` and note what changed (e.g. \"Team\" was a section header, not a\n   field; found an undocumented field the XSLT extraction missed; two similarly-named approval\n   roles are actually distinct fields). Mark the inventory **screenshot-verified**.\n3. **If screenshots aren't available or practical** (e.g. running this across a large batch of\n   forms), don't block on them. Instead:\n   - Re-check the Phase 2 inventory against the raw XSLT views a second time, specifically\n     hunting for the failure modes above (misread section headings, conditionally-rendered\n     fields, label\u002Ffield-name mismatches).\n   - Mark the inventory **XSLT-only, not screenshot-verified**, and add a \"Needs manual\n     verification\" subsection to `infopath-inventory.md` listing every field, section, and\n     rule where confidence is low (ambiguous labels, deeply nested conditional visibility,\n     anything the XSLT structure made a judgment call on).\n   - Carry this confidence flag forward into `canvas-app-prompt.md` (Phase 4) and the\n     migration log (Phase 6), so it's visible to whoever reviews or accepts the generated app,\n     and so the form can be prioritized for a screenshot pass later if one becomes available.\n4. Only after this pass, ask the user:\n   1. Mock with collections in `App.OnStart` (default), or wire to real SharePoint?\n   2. Keep all sections, or drop any?\n   3. Aesthetic preferences? (default: clean professional)\n   4. Is this migration expected to move across environments (dev\u002Ftest\u002Fprod ALM), or is it a\n      one-off \u002F single-environment build (e.g. a POC)? This decides whether Phase 5\n      (Environment Variables) runs.\n\nWait for answers.\n\n**If the user wants to wire to real SharePoint**, and they haven't already connected a\ncoauthoring session (Phase 0), do it now — Canvas can't bind to a connection that doesn't\nexist in the app. Tell them the steps (Power Apps Studio → Data → Add data → SharePoint → pick\nsite\u002Flist) and that this skill can verify the schema once it's done.\n\nWhen they confirm, call `mcp__canvas-authoring__connect` if no session is active yet, then\n`mcp__canvas-authoring__list_data_sources` to see what's connected, then\n`mcp__canvas-authoring__get_data_source_schema` for each list. Diff against the verified\ninventory: every InfoPath field should map to a SharePoint column of compatible type. Report\nany **missing columns**, **type mismatches** (e.g. InfoPath Date vs. SP Text), or\n**extra-required columns** the form doesn't populate. Pause and let the user reconcile\n(rename columns, add missing ones, or trim the inventory) before Phase 4.\n\n---\n\n## Phase 4 — Hand off to `\u002Fcanvas-app`\n\n[#phase-4--hand-off-to-canvas-app](#phase-4--hand-off-to-canvas-app)\n\nWrite `canvas-app-prompt.md` containing:\n\n- The kept sections + field lists with type hints (call out dates, multi-choice, rich text).\n- Each InfoPath rule restated as the desired Canvas behavior in plain English (the `\u002Fcanvas-app`\n  skill's discovery\u002Fdesign agents map this to Power Fx).\n- The routing\u002Fstate-machine sequence from Phase 2, restated as a screen-visibility or\n  status-gated navigation plan (e.g. \"Screen X is only reachable when Status = 'Pending Local\n  Ops Review'\"), since Canvas has no native equivalent of InfoPath's per-view `xsf` rules.\n- Mock-data plan if mocking: 3–5 sample records per section, plus choice-list collections\nseeded from enumerations \u002F lookup tables.\n- The user's aesthetic answer.\n- Validation should **block** submit (`DisplayMode.Disabled` on Save buttons) — an intentional\nupgrade from InfoPath's flag-but-don't-block behavior; flag this as a deliberate change.\n\nThen invoke `\u002Fcanvas-app` via the `Skill` tool, passing `canvas-app-prompt.md` as the\ngeneration requirements (`\u002Fcanvas-app` auto-detects create-vs-edit from the current app state,\nruns its own discovery phase against `list_controls` \u002F `list_apis` \u002F `list_data_sources`,\nproduces an app plan for approval, then fans out `canvas-screen-editor` builder agents per\nscreen in parallel and validates the result with `compile_canvas`). If `\u002Fcanvas-app` isn't\navailable, instruct the user to install `canvas-apps@power-platform-skills` (see Phase 0) and\nthen run `\u002Fcanvas-app` against `canvas-app-prompt.md` directly.\n\n---\n\n## Phase 5 — Environment Variables (Optional)\n\n[#phase-5--environment-variables-optional](#phase-5--environment-variables-optional)\n\nThis phase is **optional** and only runs if the user indicated in Phase 3 that this migration\nwill move across environments (dev\u002Ftest\u002Fprod ALM) rather than staying a one-off or\nsingle-environment build.\n\n- **If the migration is a POC \u002F single-environment build**: skip this phase. Bind the app's\n  data sources directly (real connection or mocked collections, per the Phase 3 answer) and\n  say plainly in the migration log (Phase 6) that environment variables were skipped and why,\n  so it's an explicit, visible decision rather than a silent gap — not a blocker to revisit\n  unless the app later needs to be promoted across environments.\n- **If the migration is expected to move across environments**, proceed as follows. Once the\n  app is wired to real data sources (or is about to be — this is easiest to set up right after\n  `\u002Fcanvas-app` creates the data-source connections), do **not** leave the SharePoint site URL,\n  list name\u002FGUID, environment ID, or any other connection detail hardcoded into the `.pa.yaml`.\n  Hardcoded values tie the generated app to whichever environment it happened to be built\n  against and break the moment it's promoted from dev to test to prod.\n\n  1. For each data source identified in Phase 3's diff, define a Dataverse **environment\n     variable** per connection detail that changes across environments (typically: site URL,\n     list name, and — if the app calls a Flow\u002Fconnector — the connection reference). Use clear,\n     consistent naming, e.g. `envvar_ClientBespokeProcess_SiteUrl`,\n     `envvar_ClientBespokeProcess_ListName`.\n  2. Reference the environment variable's current value in the app's `App.OnStart` (or\n     wherever the data source is bound) instead of a literal string — e.g.\n     `SharePointSiteUrl: Environment.EnvironmentVariable(\"envvar_ClientBespokeProcess_SiteUrl\")`\n     — rather than the raw URL.\n  3. Record each environment variable's schema name, purpose, and per-environment values\n     (dev\u002Ftest\u002Fprod) in `canvas-app-prompt.md` (or a companion `environment-variables.md`) so\n     they can be set as part of solution deployment rather than rediscovered later.\n  4. If the target environment doesn't yet have Dataverse environment variables\n     enabled\u002Favailable, flag this to the user before proceeding — don't silently fall back to\n     hardcoded values.\n\n---\n\n## Phase 6 — Export Migration Log\n\n[#phase-6--export-migration-log](#phase-6--export-migration-log)\n\nEvery time this skill is run against a particular `.xsn`, write (or update, on a re-run)\n`\u003Cform-name>-migration-log.md` alongside the extracted form, dated at the top. Capture:\n\n- Source `.xsn` path\u002Fname and extraction date.\n- Inventory summary (field \u002F rule \u002F connection \u002F section \u002F stage counts from Phase 2).\n- Phase 3 verification method and confidence: whether the inventory is\n  **screenshot-verified** or **XSLT-only**, every correction made if screenshots were used\n  (what the screenshots caught that the XSLT extraction got wrong), and — if screenshots\n  weren't available — the full \"Needs manual verification\" list carried over from\n  `infopath-inventory.md`, so future re-runs, audits, or a later screenshot pass don't have to\n  rediscover which areas are still unconfirmed.\n- The decisions captured before handoff: mock vs. real SharePoint, sections kept\u002Fdropped,\n  aesthetic direction, and whether this migration is ALM (dev\u002Ftest\u002Fprod) or single-environment.\n- Phase 5 outcome: either the environment variables defined and what they point to, or an\n  explicit note that Phase 5 was skipped (single-environment\u002FPOC) and why.\n- The outcome of the `\u002Fcanvas-app` handoff: app name\u002Flocation, whether `compile_canvas`\n  passed cleanly or needed fixes, and any deliberate behavior changes from InfoPath (e.g. the\n  block-on-submit validation change).\n\nThis log is the artifact to hand to a customer or reviewer as evidence of what changed and\nwhy — write it in plain language, not as a raw dump of the phase outputs.\n",{"name":5,"version":48,"description":7,"allowed-tools":49,"user-invocable":50},"2.2.0","Read, Write, Edit, Bash, Glob, Grep, PowerShell, Agent, TaskCreate, TaskUpdate, TaskList, Skill, EnterPlanMode, ExitPlanMode",true,"main","30bfe45d279a77276e71a3ac58c35119fc194365","Power Platform Migration Factory\u002Finfopath-to-canvas",20,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 00:21:20",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":50},[62,65,68],{"tool":63,"command":64},"npx","npx skills add microsoft\u002Fpower-cat-skills --skill infopath-to-canvas",{"tool":66,"command":67},"bunx","bunx skills add microsoft\u002Fpower-cat-skills --skill infopath-to-canvas",{"tool":69,"command":70},"pnpm","pnpm dlx skills add microsoft\u002Fpower-cat-skills --skill infopath-to-canvas","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002FPower Platform Migration Factory\u002Finfopath-to-canvas\u002FSKILL.md",[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"README.md","REFERENCE","参考文档",2916,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002FPower Platform Migration Factory\u002Finfopath-to-canvas\u002FREADME.md",[80,106,143,168,191,210],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":89,"publishedAt":43},"01M711KHT2PNDCPT1AJ06PRTAD","powercat-skills-router","Route Microsoft Power Platform requests to the best-fit specialist skill across microsoft\u002Fpower-cat-skills and microsoft\u002Fpower-platform-skills. Use when a user asks which skill can help, wants to find or use a Power Platform skill, or requests work involving Power Apps, Power Automate, Power Pages, Dataverse, Copilot Studio, or Power Platform administration. Discover candidates, reconcile installation and updates, obtain approval for changes, load the selected skill, and continue the original task.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-skills-router\u002Fskills\u002Fpowercat-skills-router\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[90,91,92,93,34,94,32,27,95,96,97,98,99,100,101,102,103,104,28,105],"router","powercat skills router","which","discover","copilot","updates","copilot studio","dataverse","studio","across","route","work","reconcile","automate","platform","fit",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":126,"publishedAt":43},"01M711KBER1KD9NQQ1NSDMF8F1","eval-generator-gen-pages","Generate a three-layer eval suite (presence checks + unit tests + security analysis) for Power Apps Generative Pages in Model-Driven Apps. Generative pages are single-file React\u002FTypeScript components using Fluent UI V9 and the dataApi prop for Dataverse operations — NOT Code Apps, NOT PCF components. Code may be generated by the App Agent in make.powerapps.com or by AI code generation tools (Claude Code, GitHub Copilot CLI) using the \u002Fgenpage skill. Always produces: evals\u002Fmanifest.json, evals\u002Fpresence\u002F\u003Cid>.check.ts, evals\u002Funit\u002F\u003Cfeature>.test.tsx, evals\u002Frunner\u002Frun-evals.ts, evals\u002Frunner\u002Fpresence-runner.ts, evals\u002Frunner\u002Fsecurity-runner.ts, and evals\u002Fdashboard\u002Findex.html. Triggers: 'eval my generative page', 'generate evals for gen page', 'review my genpage code', 'test my generative page', 'check my model driven app page', 'eval generator gen pages'.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-procode-eval\u002Fskills\u002Feval-generator-gen-pages\u002FSKILL.md",[112,115,118,121],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[127,128,129,130,131,132,33,133,34,134,32,135,97,136,137,138,139,140,141,142],"eval","generator","eval generator","eval generator gen pages","pages","unit","tsx","generative","URL","components","fluent","react","github copilot cli","generate","eval suite","run",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":158,"publishedAt":43},"01M711K4VSKBM85NYF3C5QQZQF","eval-generator-code-app","Generate a two-layer eval suite (presence checks + static security analysis) for a Power Apps Code App. Code Apps use @microsoft\u002Fpower-apps SDK with generated service classes in src\u002Fgenerated\u002Fservices\u002F — NOT @microsoft\u002Fpowerapps-component-framework or context.webAPI.*. BRD is optional — if absent, features are derived from a code review of the project. Always produces: evals\u002Fmanifest.json, evals\u002Fpresence\u002F\u003Cid>.check.ts files, evals\u002Frunner\u002Frun-evals.ts, evals\u002Frunner\u002Fpresence-runner.ts, evals\u002Frunner\u002Fsecurity-runner.ts, and evals\u002Fdashboard\u002Findex.html. Triggers: 'generate code app evals', 'eval my code app', 'generate tests for code app', 'code app eval generator', 'check feature completeness code app'.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-procode-eval\u002Fskills\u002Feval-generator-code-app\u002FSKILL.md",[149,152,153,154,157],{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":155,"categoryName":156,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[33,127,128,129,159,160,34,161,162,163,164,32,135,165,140,141,142,166,167,28],"code","eval generator code app","project","static","code review","files","component","security","context",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":43},"01M711JZEWX0N2D7EA74YBCJ9G","powercat-overpage","Reviews the Power Pages site(s) inside a Power Platform solution .zip against best practices across Security, Performance, Accessibility, Maintainability, Architecture and Reliability — by reading the pages, web templates, custom JS\u002FCSS, settings and table permissions and reasoning about them. Optionally also ingests a browser HAR capture (recommended) to investigate real performance bottlenecks and map them to code. Produces a [SolutionName].findings.json (validated against findings.schema.json) with solution-level, per-site and per-component findings, each with a description, a suggested fix, and (where relevant) a code or HAR anchor. Then opens the PowerCAT OverPage viewer with the solution, findings and HAR loaded so the user can explore findings overlaid on a live page preview, on the actual code, and on the network waterfall. Triggers: 'powercat overpage', 'overpage my site', 'review my power pages site', 'review this portal solution', 'evaluate this power pages solution', 'audit power pages site', 'overpage', 'power pages solution review', 'analyze power pages performance', 'review power pages with har'.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-overpage\u002Fskills\u002Fpowercat-overpage\u002FSKILL.md",[],[175,176,177,178,179,34,180,181,182,183,184,159,185,186,99,187,188,189,165,190],"powercat overpage","reviews","reliability","relevant","css","performance","explore","fix","map","preview","architecture","review","analyze","browser","permissions","audit",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":43},"01M711JWDD22RDQ4HG6XD3V96F","powercat-overflow","Reviews every Power Automate cloud flow inside a Power Platform solution (.zip) against Microsoft's coding guidelines and produces a [SolutionName].findings.json next to the uploaded solution, then opens the hosted PowerCAT-Overflow viewer at https:\u002F\u002Fmicrosoft.github.io\u002Fpower-cat-skills\u002FPowerCAT-Overflow.html and uploads both files so the user can explore the results. Triggers: 'powercat overflow', 'overflow my solution', 'review my solution', 'evaluate flows in this solution', 'audit Power Auto","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-overflow\u002Fskills\u002Fpowercat-overflow\u002FSKILL.md",[],[198,176,34,181,199,164,200,186,201,202,190,203,204,205,206,207,103,208,209,104],"powercat overflow","flows","auto","io","next","at","flow","my","coding","html","viewer","zip",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":220,"publishedAt":43},"01M711JRDNTWN8E2JXEE5GHB9A","dev-environment-deprecation-report","Builds a \"Developer Environments Deprecation Report\" (HTML) for any Power Platform tenant: days left until\nunmanaged developer environments are suspended, which ones are unmanaged, the apps, flows and agents at risk,\nenvironments created on behalf of other makers, and makers over the one-per-maker limit. Uses the Power\nPlatform for Admins connectors and a bundled generator script. Use when the user asks for a \"developer\nenvironment report\", \"unmanaged developer environments\", \"dev environment deprecation\", \"created on behalf\nof developer environments\", \"one PDE per maker\" or \"days left until developer environment suspension\".\nDo NOT use for production, sandbox, default or Teams environment reports, or general\ninventory\u002Fusage questions — use ask-power-platform-advisor instead.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-cat-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpowercat-governance\u002Fskills\u002Fdev-environment-deprecation-report\u002FSKILL.md",[216,217],{"categoryNo":155,"categoryName":156,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":218,"categoryName":219,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000034","行政与办公人员",[221,222,223,224,225,226,227,92,34,228,229,199,230,32,27,231,232,233,234,203],"deprecation","dev environment deprecation report","environment","dev","dev environment","report","tenant","maker","inventory","default","ask","analysis","reports","advisor"]