[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699PZDFXG6JQWW40C25PVB8":3,"skill-same:01M699PZDFXG6JQWW40C25PVB8":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":67,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":84},"01M699PZDFXG6JQWW40C25PVB8","pcf",null,"Builds, tests, diagnoses, upgrades, deploys and verifies Power Apps component framework (PCF) code components for model-driven apps and Power Pages — field and dataset controls, standard and virtual (React) — from Microsoft-maintained templates and recipes pinned to a tested version matrix. Runs quality gates (manifest and host lint, source checks, lint, unit tests, production build), deploys with pac pcf push, verifies registration and form bindings, and guides Power Pages enablement, with guided setup for canvas apps. Use when the user wants to build, fix, upgrade, deploy or check a PCF control or code component, or asks why one fails to build, import, update or render. For a whole page use \u002Fmodel-apps:genpage; for a whole app use \u002Fmodel-apps:app-builder.","microsoft\u002Fpower-platform-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699JVYJFB75D9JM70BN4H0Q",1132,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,9,51],"search","unit","guides","apps","host","app","upgrade","todo","power","fix","edit","write","read","why","canvas","update","genpage","deploy","power pages","power apps","unit tests","component","react","components","web","2026-11-10 10:12:30",false,"---\nname: pcf\nversion: 1.0.0\ndescription: Builds, tests, diagnoses, upgrades, deploys and verifies Power Apps component framework (PCF) code components for model-driven apps and Power Pages — field and dataset controls, standard and virtual (React) — from Microsoft-maintained templates and recipes pinned to a tested version matrix. Runs quality gates (manifest and host lint, source checks, lint, unit tests, production build), deploys with pac pcf push, verifies registration and form bindings, and guides Power Pages enablement, with guided setup for canvas apps. Use when the user wants to build, fix, upgrade, deploy or check a PCF control or code component, or asks why one fails to build, import, update or render. For a whole page use \u002Fmodel-apps:genpage; for a whole app use \u002Fmodel-apps:app-builder.\nauthor: Microsoft Corporation\nargument-hint: \"\u003Ccontrol description> | doctor | upgrade | verify | inventory\"\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, WebFetch, AskUserQuestion, EnterPlanMode, ExitPlanMode, TaskCreate, TaskUpdate, TaskList, read, edit, execute, search, web, todo\n---\r\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# PCF skill\n\nBuild, repair, upgrade, deploy, bind, verify and inventory Power Apps component framework controls. Run the work in the main conversation loop. Do not dispatch interactive authoring, approval, deploy consent, binding choices or browser-verification choices to a subagent.\n\n## Critical startup\n\n1. Set `PLUGIN_ROOT` to the installed `plugins\u002Fpcf` directory.\n2. Resolve interaction once:\n   ```powershell\n   node \"${PLUGIN_ROOT}\u002Fscripts\u002Fresolve-interaction-mode.js\"\r\n   # Optional for automation: --non-interactive\n   ```\n3. In unattended mode, do not call `AskUserQuestion`, `EnterPlanMode` or `ExitPlanMode`. Use explicit request details and documented non-destructive defaults only; write `Unattended default: \u003Cquestion> → \u003Canswer> (\u003Creason>)` to `workflow-log.md` in the session working directory; halt on ambiguous environment, app\u002Fform\u002Fcontrol identity or destructive choices. `pcf-intent.json`, `pcf-plan.md` and `workflow-log.md` live in that working directory. `hooks\u002Fvalidate-write-safety.js` detects a pcf session only from `pcf-intent.json` or `pcf-plan.md` at or one level under the cwd; `workflow-log.md` is not a session marker. `--out` must be a new, empty subdirectory. Never write those session files into `--out` before scaffold runs — a non-empty directory is refused.\n4. Suppressing a prompt never authorizes an environment write. `pcf-push.js` still requires an explicit `--env` and prior consent recorded by the user or automation.\n\n## Routing\n\n| User intent | Route |\n| --- | --- |\n| Build, fix, upgrade, deploy, bind, verify, inventory a PCF code component | Stay in `\u002Fpcf:pcf`. |\n| Why a PCF control will not build, import, update or render | Stay in `\u002Fpcf:pcf`; start with [..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md](..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md) and the doctor output. |\n| Whole custom page \u002F generative page | Use `\u002Fmodel-apps:genpage`. |\n| Whole model-driven app with tables\u002Fforms\u002Fviews\u002Fpages | Use `\u002Fmodel-apps:app-builder`. |\n| Use an existing control without code changes | Guide Maker binding and verification; do not scaffold. |\n\n## Modes — detect, then confirm\n\n- **new**: no PCF project exists or the user asks to create one. Follow [create-flow.md](create-flow.md).\n- **existing project**: one `*.pcfproj` found. Iterate, gates, deploy-only or bind as requested. If several are found, ask which unless unattended supplied a path.\n- **verify**: existing control already registered\u002Fbound. Run `verify-pcf.js` or `pcf-inventory.js` as appropriate.\n- **pages**: user targets Power Pages. This release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Run the Pages compatibility gate before deploy or acceptance, then guide site configuration after deploy. Follow [pages-flow.md](pages-flow.md).\n- **canvas**: user targets canvas apps. Setup is guided only: gate with the model-driven profile (`model` in the intent and `--hosts`, the gates' default; never `canvas`), keep `pages` as well when the control also targets Power Pages, and review canvas API limits by hand with the user. After the normal push flow, guide the environment setting and Studio setup using [..\u002F..\u002Freferences\u002Fpcf-canvas.md](..\u002F..\u002Freferences\u002Fpcf-canvas.md). A canvas gate profile, reading the environment setting and automated runtime evidence are not implemented.\n- **doctor**: run `pcf-doctor.js` and stop with fixes unless user asked to apply a repair.\n- **upgrade**: follow [upgrade-flow.md](upgrade-flow.md).\n- **inventory \u002F \"is this control still used?\"**: run `pcf-inventory.js --env \u003Curl> --where-used`; always include the where-used warning from `pcf-testing.md` because dependency results are registered solution dependencies only, not proof of Liquid or arbitrary text references.\n\n## Phase 0 — preflight\n\nRun the smallest doctor for the requested work:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-doctor.js\" [--project \u003Cdir>] [--hosts model,pages] [--needs build,push]\n```\n\nWhen an environment is involved, also run:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fcheck-auth.js\" --env \u003CenvUrl> [--require-pac]\n```\n\nUse `--require-pac` only for push\u002Fpackage paths and any other path that invokes PAC. Verification and inventory use Azure CLI plus Dataverse reads, so they require `az` auth but not PAC. If auth or tools block, report the script's JSON message and stop.\n\nFor repair work, read [..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md](..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md) before choosing fixes. It maps build\u002Fimport\u002Fupdate\u002Frender symptoms to the checks and scripts that produce actionable evidence.\n\n## Phase 1 — design → intent → plan approval\n\nAsk only the missing decisions: host(s), field vs dataset, template family, properties, required features, target solution\u002Fpublisher, binding target, clients, Pages journey, and guided canvas setup. For new controls follow [create-flow.md](create-flow.md).\n\nWrite `pcf-intent.json` with schema version 1, then render the plan:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fwrite-pcf-plan.js\" --intent @pcf-intent.json [--manifest ControlManifest.Input.xml] [--out pcf-plan.md]\n```\n\nIn attended mode, show the rendered plan in plan mode and continue only after approval. In unattended mode, treat a green plan plus explicit non-destructive defaults as approved and log that default.\n\n## Phase 2 — scaffold\n\nFor new work, list templates and recipes first:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-scaffold.js\" --list\n```\n\nThen scaffold exactly what the approved intent names:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-scaffold.js\" --template \u003Cid> --namespace \u003CNamespace> --name \u003CControlName> --out \u003Cdir> [--hosts model,pages] [--recipe \u003Cid>] [--display-name \u003Ctext>] [--description \u003Ctext>] [--install] [--npm-cli \u003Cpath>]\n```\n\nIf the scaffold JSON includes the `PCF_SCAFFOLD_OUT_REDIRECTED` note, tell the user the files were written to `resolvedOutDir`. That note is an `info` finding, not a warning, and appears only when `--out` resolved through a symlink or junction. Checks and writes used that physical path; `outDir` is only the path that was requested.\n\nDo not hand-copy template files. Recipes are routing aids; each current recipe is designed for its listed hosts but **not certified in this release** unless `pcf-recipes.md` shows a certification date.\n\n## Phase 3 — implement\n\nRead [..\u002F..\u002Freferences\u002Fpcf-best-practices.md](..\u002F..\u002Freferences\u002Fpcf-best-practices.md), [..\u002F..\u002Freferences\u002Fpcf-hosts.md](..\u002F..\u002Freferences\u002Fpcf-hosts.md), [..\u002F..\u002Freferences\u002Fpcf-testing.md](..\u002F..\u002Freferences\u002Fpcf-testing.md), and the selected recipe's README, if a recipe was selected (`recipes\u002F\u003Cid>\u002FREADME.md`). Keep versions from the matrix and lockfiles only. Add or preserve tests for null-first rendering, missing parameters, field security, permission failures, two instances and dataset paging where applicable.\n\n## Phase 4 — gates loop\n\nRun gates until green:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-gates.js\" --project \u003Cdir> [--hosts model,pages] [--skip lint,test,build]\n```\n\nUse `--skip` only for an explicitly irrelevant gate, and explain why. Never weaken a gate, delete a test, remove deployed-only code, or switch hosts just to pass. For a build-only check:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-build.js\" --project \u003Cdir> [--mode production|development] [--no-clean]\n```\n\nBefore redeploying an existing control, compare the current manifest with the previous manifest when a baseline is available:\n\n```powershell\ngit show \u003Cref>:\u003Cpath>\u002FControlManifest.Input.xml > \u003Ctemp-old-manifest>\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Flint-pcf.js\" --manifest \u003Ccurrent manifest> --against \u003Ctemp-old-manifest> [--hosts model,pages] [--strict]\n```\n\nIf no previous manifest is available, state that compatibility was not compared; do not claim the redeploy is backwards-compatible from gates alone.\n\n## Phase 5 — Pages compatibility gate\n\nFor controls targeting Power Pages, run the pre-deploy Pages gate before `pcf-push.js`:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-gates.js\" --project \u003Cdir> --hosts pages\n```\n\nThis release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Reject dataset Pages targets, unsupported control types, unsupported manifest features and source patterns documented in [..\u002F..\u002Freferences\u002Fpcf-power-pages.md](..\u002F..\u002Freferences\u002Fpcf-power-pages.md) before deploy. Keep the field and Liquid site-configuration journeys for after deployment.\n\n## Phase 6 — deploy\n\nFollow [deploy-flow.md](deploy-flow.md). Before running `pcf-push.js`, obtain and record consent naming: environment origin, solution or publisher prefix, and the fact that `pac pcf push` publishes all pending customizations in that environment.\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-push.js\" --project \u003Cdir> --env \u003Curl> (--solution \u003CuniqueName> | --publisher-prefix \u003Cp>) [--incremental] [--verbosity minimal|normal|detailed|diagnostic] [--allow-dev-bundle] [--no-verify]\n```\n\n## Phase 7 — bind\n\nFor model-driven targets and Power Pages form-field journeys, follow [bind-flow.md](bind-flow.md). Use Maker for binding unless the user explicitly brought their own binding automation. Publish after binding before claiming a published level. For canvas-only targets, skip model-driven form binding and follow the canvas setup below.\n\n## Phase 8 — verify and optional runtime check\n\nFor canvas-only targets, use the push registration read-back or `pcf-inventory.js` for registration evidence, not FormXML verification. For model-driven targets and Power Pages form-field journeys, verify metadata:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fverify-pcf.js\" --env \u003Curl> --control \u003Cprefix_ns.ctor> [--version \u003Cx.y.z>] --table \u003Clogical> --form \u003Cname|guid> (--column \u003Ccol>|--control-id \u003Cid>) [--clients web,phone,tablet] [--param name=column:\u003Ccol>] [--param name=static:\u003Cvalue>[:\u003Ctype>]] [--workspace \u003Cdir>]\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fverify-pcf.js\" --env \u003Curl> --control \u003Cprefix_ns.ctor> [--version \u003Cx.y.z>] --intent @pcf-intent.json [--workspace \u003Cdir>]\n```\n\nFor model-driven apps and Pages sites, offer a browser runtime check with Playwright MCP when a reachable target exists. If skipped or unavailable, report `runtime-not-checked` honestly. Canvas runtime checks are manual in Power Apps Studio.\n\n## Phase 9 — Pages site configuration and canvas setup\n\nFor Power Pages targets after deployment, follow [pages-flow.md](pages-flow.md), [..\u002F..\u002Freferences\u002Fpcf-power-pages.md](..\u002F..\u002Freferences\u002Fpcf-power-pages.md), and the host matrix to guide site configuration. This release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Do not claim Pages runtime certification without opening the site and recording behavior.\n\nFor canvas targets after a successful push, follow [..\u002F..\u002Freferences\u002Fpcf-canvas.md](..\u002F..\u002Freferences\u002Fpcf-canvas.md) to guide an admin through **Power Apps component framework for canvas apps** and the user through Studio import\u002Fsetup. Do not read or change the setting automatically. Report `runtime-not-checked` unless the user checks the control in Power Apps Studio; registration and import are not runtime evidence.\n\n## Upgrade and inventory shortcuts\n\n- Upgrade: [upgrade-flow.md](upgrade-flow.md), then gates, redeploy and verify.\n- Inventory:\n  ```powershell\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-inventory.js\" --env \u003Curl> [--control \u003Cname>] [--include-managed] [--where-used] [--workspace \u003Cdir>]\n  ```\n- Lint a manifest directly:\n  ```powershell\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Flint-pcf.js\" (--manifest \u003Cfile> | --project \u003Cdir>) [--hosts model,pages] [--against \u003Cold manifest>] [--strict]\n  ```\n\n## Reporting and evidence levels\n\n| Level | What you may claim | Script or proof |\n| --- | --- | --- |\n| `built` | Production build completed locally. | `pcf-build.js --project \u003Cdir> --mode production` or `pcf-gates.js --project \u003Cdir>` build phase. |\n| `gated` | Manifest, host, source, lint, tests and build passed. | `pcf-gates.js` green. |\n| `registered` | Dataverse has the expected control\u002Fversion. | `pcf-push.js` verification or `verify-pcf.js`. |\n| `bound(draft)` | Draft form\u002Fgrid metadata uses the control. | `verify-pcf.js` draft read. |\n| `bound(published)` | Published metadata uses the control. | `verify-pcf.js` published read after publish. |\n| `runtime-verified` | Target host loaded and journey worked. | Browser\u002FPlaywright\u002Fmanual smoke evidence. |\n| `runtime-not-checked` | Metadata was checked but runtime was not. | State explicitly; do not round up. |\n\nFinal report: control identity, hosts, version, gates, deploy target as a safe placeholder such as `https:\u002F\u002Fcontoso.crm.dynamics.com`, evidence level, runtime status, Pages status, canvas status, and inventory warning.\r\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# PCF skill\n\nBuild, repair, upgrade, deploy, bind, verify and inventory Power Apps component framework controls. Run the work in the main conversation loop. Do not dispatch interactive authoring, approval, deploy consent, binding choices or browser-verification choices to a subagent.\n\n## Critical startup\n\n1. Set `PLUGIN_ROOT` to the installed `plugins\u002Fpcf` directory.\n2. Resolve interaction once:\n   ```powershell\n   node \"${PLUGIN_ROOT}\u002Fscripts\u002Fresolve-interaction-mode.js\"\r\n   # Optional for automation: --non-interactive\n   ```\n3. In unattended mode, do not call `AskUserQuestion`, `EnterPlanMode` or `ExitPlanMode`. Use explicit request details and documented non-destructive defaults only; write `Unattended default: \u003Cquestion> → \u003Canswer> (\u003Creason>)` to `workflow-log.md` in the session working directory; halt on ambiguous environment, app\u002Fform\u002Fcontrol identity or destructive choices. `pcf-intent.json`, `pcf-plan.md` and `workflow-log.md` live in that working directory. `hooks\u002Fvalidate-write-safety.js` detects a pcf session only from `pcf-intent.json` or `pcf-plan.md` at or one level under the cwd; `workflow-log.md` is not a session marker. `--out` must be a new, empty subdirectory. Never write those session files into `--out` before scaffold runs — a non-empty directory is refused.\n4. Suppressing a prompt never authorizes an environment write. `pcf-push.js` still requires an explicit `--env` and prior consent recorded by the user or automation.\n\n## Routing\n\n| User intent | Route |\n| --- | --- |\n| Build, fix, upgrade, deploy, bind, verify, inventory a PCF code component | Stay in `\u002Fpcf:pcf`. |\n| Why a PCF control will not build, import, update or render | Stay in `\u002Fpcf:pcf`; start with [..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md](..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md) and the doctor output. |\n| Whole custom page \u002F generative page | Use `\u002Fmodel-apps:genpage`. |\n| Whole model-driven app with tables\u002Fforms\u002Fviews\u002Fpages | Use `\u002Fmodel-apps:app-builder`. |\n| Use an existing control without code changes | Guide Maker binding and verification; do not scaffold. |\n\n## Modes — detect, then confirm\n\n- **new**: no PCF project exists or the user asks to create one. Follow [create-flow.md](create-flow.md).\n- **existing project**: one `*.pcfproj` found. Iterate, gates, deploy-only or bind as requested. If several are found, ask which unless unattended supplied a path.\n- **verify**: existing control already registered\u002Fbound. Run `verify-pcf.js` or `pcf-inventory.js` as appropriate.\n- **pages**: user targets Power Pages. This release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Run the Pages compatibility gate before deploy or acceptance, then guide site configuration after deploy. Follow [pages-flow.md](pages-flow.md).\n- **canvas**: user targets canvas apps. Setup is guided only: gate with the model-driven profile (`model` in the intent and `--hosts`, the gates' default; never `canvas`), keep `pages` as well when the control also targets Power Pages, and review canvas API limits by hand with the user. After the normal push flow, guide the environment setting and Studio setup using [..\u002F..\u002Freferences\u002Fpcf-canvas.md](..\u002F..\u002Freferences\u002Fpcf-canvas.md). A canvas gate profile, reading the environment setting and automated runtime evidence are not implemented.\n- **doctor**: run `pcf-doctor.js` and stop with fixes unless user asked to apply a repair.\n- **upgrade**: follow [upgrade-flow.md](upgrade-flow.md).\n- **inventory \u002F \"is this control still used?\"**: run `pcf-inventory.js --env \u003Curl> --where-used`; always include the where-used warning from `pcf-testing.md` because dependency results are registered solution dependencies only, not proof of Liquid or arbitrary text references.\n\n## Phase 0 — preflight\n\nRun the smallest doctor for the requested work:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-doctor.js\" [--project \u003Cdir>] [--hosts model,pages] [--needs build,push]\n```\n\nWhen an environment is involved, also run:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fcheck-auth.js\" --env \u003CenvUrl> [--require-pac]\n```\n\nUse `--require-pac` only for push\u002Fpackage paths and any other path that invokes PAC. Verification and inventory use Azure CLI plus Dataverse reads, so they require `az` auth but not PAC. If auth or tools block, report the script's JSON message and stop.\n\nFor repair work, read [..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md](..\u002F..\u002Freferences\u002Fpcf-troubleshooting.md) before choosing fixes. It maps build\u002Fimport\u002Fupdate\u002Frender symptoms to the checks and scripts that produce actionable evidence.\n\n## Phase 1 — design → intent → plan approval\n\nAsk only the missing decisions: host(s), field vs dataset, template family, properties, required features, target solution\u002Fpublisher, binding target, clients, Pages journey, and guided canvas setup. For new controls follow [create-flow.md](create-flow.md).\n\nWrite `pcf-intent.json` with schema version 1, then render the plan:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fwrite-pcf-plan.js\" --intent @pcf-intent.json [--manifest ControlManifest.Input.xml] [--out pcf-plan.md]\n```\n\nIn attended mode, show the rendered plan in plan mode and continue only after approval. In unattended mode, treat a green plan plus explicit non-destructive defaults as approved and log that default.\n\n## Phase 2 — scaffold\n\nFor new work, list templates and recipes first:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-scaffold.js\" --list\n```\n\nThen scaffold exactly what the approved intent names:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-scaffold.js\" --template \u003Cid> --namespace \u003CNamespace> --name \u003CControlName> --out \u003Cdir> [--hosts model,pages] [--recipe \u003Cid>] [--display-name \u003Ctext>] [--description \u003Ctext>] [--install] [--npm-cli \u003Cpath>]\n```\n\nIf the scaffold JSON includes the `PCF_SCAFFOLD_OUT_REDIRECTED` note, tell the user the files were written to `resolvedOutDir`. That note is an `info` finding, not a warning, and appears only when `--out` resolved through a symlink or junction. Checks and writes used that physical path; `outDir` is only the path that was requested.\n\nDo not hand-copy template files. Recipes are routing aids; each current recipe is designed for its listed hosts but **not certified in this release** unless `pcf-recipes.md` shows a certification date.\n\n## Phase 3 — implement\n\nRead [..\u002F..\u002Freferences\u002Fpcf-best-practices.md](..\u002F..\u002Freferences\u002Fpcf-best-practices.md), [..\u002F..\u002Freferences\u002Fpcf-hosts.md](..\u002F..\u002Freferences\u002Fpcf-hosts.md), [..\u002F..\u002Freferences\u002Fpcf-testing.md](..\u002F..\u002Freferences\u002Fpcf-testing.md), and the selected recipe's README, if a recipe was selected (`recipes\u002F\u003Cid>\u002FREADME.md`). Keep versions from the matrix and lockfiles only. Add or preserve tests for null-first rendering, missing parameters, field security, permission failures, two instances and dataset paging where applicable.\n\n## Phase 4 — gates loop\n\nRun gates until green:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-gates.js\" --project \u003Cdir> [--hosts model,pages] [--skip lint,test,build]\n```\n\nUse `--skip` only for an explicitly irrelevant gate, and explain why. Never weaken a gate, delete a test, remove deployed-only code, or switch hosts just to pass. For a build-only check:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-build.js\" --project \u003Cdir> [--mode production|development] [--no-clean]\n```\n\nBefore redeploying an existing control, compare the current manifest with the previous manifest when a baseline is available:\n\n```powershell\ngit show \u003Cref>:\u003Cpath>\u002FControlManifest.Input.xml > \u003Ctemp-old-manifest>\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Flint-pcf.js\" --manifest \u003Ccurrent manifest> --against \u003Ctemp-old-manifest> [--hosts model,pages] [--strict]\n```\n\nIf no previous manifest is available, state that compatibility was not compared; do not claim the redeploy is backwards-compatible from gates alone.\n\n## Phase 5 — Pages compatibility gate\n\nFor controls targeting Power Pages, run the pre-deploy Pages gate before `pcf-push.js`:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-gates.js\" --project \u003Cdir> --hosts pages\n```\n\nThis release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Reject dataset Pages targets, unsupported control types, unsupported manifest features and source patterns documented in [..\u002F..\u002Freferences\u002Fpcf-power-pages.md](..\u002F..\u002Freferences\u002Fpcf-power-pages.md) before deploy. Keep the field and Liquid site-configuration journeys for after deployment.\n\n## Phase 6 — deploy\n\nFollow [deploy-flow.md](deploy-flow.md). Before running `pcf-push.js`, obtain and record consent naming: environment origin, solution or publisher prefix, and the fact that `pac pcf push` publishes all pending customizations in that environment.\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-push.js\" --project \u003Cdir> --env \u003Curl> (--solution \u003CuniqueName> | --publisher-prefix \u003Cp>) [--incremental] [--verbosity minimal|normal|detailed|diagnostic] [--allow-dev-bundle] [--no-verify]\n```\n\n## Phase 7 — bind\n\nFor model-driven targets and Power Pages form-field journeys, follow [bind-flow.md](bind-flow.md). Use Maker for binding unless the user explicitly brought their own binding automation. Publish after binding before claiming a published level. For canvas-only targets, skip model-driven form binding and follow the canvas setup below.\n\n## Phase 8 — verify and optional runtime check\n\nFor canvas-only targets, use the push registration read-back or `pcf-inventory.js` for registration evidence, not FormXML verification. For model-driven targets and Power Pages form-field journeys, verify metadata:\n\n```powershell\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fverify-pcf.js\" --env \u003Curl> --control \u003Cprefix_ns.ctor> [--version \u003Cx.y.z>] --table \u003Clogical> --form \u003Cname|guid> (--column \u003Ccol>|--control-id \u003Cid>) [--clients web,phone,tablet] [--param name=column:\u003Ccol>] [--param name=static:\u003Cvalue>[:\u003Ctype>]] [--workspace \u003Cdir>]\nnode \"${PLUGIN_ROOT}\u002Fscripts\u002Fverify-pcf.js\" --env \u003Curl> --control \u003Cprefix_ns.ctor> [--version \u003Cx.y.z>] --intent @pcf-intent.json [--workspace \u003Cdir>]\n```\n\nFor model-driven apps and Pages sites, offer a browser runtime check with Playwright MCP when a reachable target exists. If skipped or unavailable, report `runtime-not-checked` honestly. Canvas runtime checks are manual in Power Apps Studio.\n\n## Phase 9 — Pages site configuration and canvas setup\n\nFor Power Pages targets after deployment, follow [pages-flow.md](pages-flow.md), [..\u002F..\u002Freferences\u002Fpcf-power-pages.md](..\u002F..\u002Freferences\u002Fpcf-power-pages.md), and the host matrix to guide site configuration. This release supports Power Pages only for standard field controls: the form-field journey and the standalone Liquid journey (`{% codecomponent %}`), both guided. Dataset controls on Pages (form sub-grid and list) are not supported in this release. Do not claim Pages runtime certification without opening the site and recording behavior.\n\nFor canvas targets after a successful push, follow [..\u002F..\u002Freferences\u002Fpcf-canvas.md](..\u002F..\u002Freferences\u002Fpcf-canvas.md) to guide an admin through **Power Apps component framework for canvas apps** and the user through Studio import\u002Fsetup. Do not read or change the setting automatically. Report `runtime-not-checked` unless the user checks the control in Power Apps Studio; registration and import are not runtime evidence.\n\n## Upgrade and inventory shortcuts\n\n- Upgrade: [upgrade-flow.md](upgrade-flow.md), then gates, redeploy and verify.\n- Inventory:\n  ```powershell\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Fpcf-inventory.js\" --env \u003Curl> [--control \u003Cname>] [--include-managed] [--where-used] [--workspace \u003Cdir>]\n  ```\n- Lint a manifest directly:\n  ```powershell\n  node \"${PLUGIN_ROOT}\u002Fscripts\u002Flint-pcf.js\" (--manifest \u003Cfile> | --project \u003Cdir>) [--hosts model,pages] [--against \u003Cold manifest>] [--strict]\n  ```\n\n## Reporting and evidence levels\n\n| Level | What you may claim | Script or proof |\n| --- | --- | --- |\n| `built` | Production build completed locally. | `pcf-build.js --project \u003Cdir> --mode production` or `pcf-gates.js --project \u003Cdir>` build phase. |\n| `gated` | Manifest, host, source, lint, tests and build passed. | `pcf-gates.js` green. |\n| `registered` | Dataverse has the expected control\u002Fversion. | `pcf-push.js` verification or `verify-pcf.js`. |\n| `bound(draft)` | Draft form\u002Fgrid metadata uses the control. | `verify-pcf.js` draft read. |\n| `bound(published)` | Published metadata uses the control. | `verify-pcf.js` published read after publish. |\n| `runtime-verified` | Target host loaded and journey worked. | Browser\u002FPlaywright\u002Fmanual smoke evidence. |\n| `runtime-not-checked` | Metadata was checked but runtime was not. | State explicitly; do not round up. |\n\nFinal report: control identity, hosts, version, gates, deploy target as a safe placeholder such as `https:\u002F\u002Fcontoso.crm.dynamics.com`, evidence level, runtime status, Pages status, canvas status, and inventory warning.\r\n",{"name":5,"author":57,"version":58,"description":7,"allowed-tools":59,"argument-hint":60,"user-invocable":61},"Microsoft Corporation","1.0.0","Read, Write, Edit, Bash, Glob, Grep, WebFetch, AskUserQuestion, EnterPlanMode, ExitPlanMode, TaskCreate, TaskUpdate, TaskList, read, edit, execute, search, web, todo","\u003Ccontrol description> | doctor | upgrade | verify | inventory",true,"main","0a55a88fa2855404029d1e5450faf92878baf763","plugins\u002Fpcf\u002Fskills\u002Fpcf",227,"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-11 07:04:11",{"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 pcf",{"tool":78,"command":79},"bunx","bunx skills add microsoft\u002Fpower-platform-skills --skill pcf",{"tool":81,"command":82},"pnpm","pnpm dlx skills add microsoft\u002Fpower-platform-skills --skill pcf","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002FSKILL.md",[85,91,95,99,103],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"bind-flow.md","REFERENCE","参考文档",3508,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002Fbind-flow.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"create-flow.md",7892,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002Fcreate-flow.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"deploy-flow.md",5061,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002Fdeploy-flow.md",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"pages-flow.md",4506,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002Fpages-flow.md",{"path":104,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":105,"sourceHtmlUrl":106},"upgrade-flow.md",4180,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fpcf\u002Fskills\u002Fpcf\u002Fupgrade-flow.md",[108,129,152,170,184,194],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":52},"01M699WVHX0XN59EPBTTPEKYPG","setup","Use when Process Intelligence needs building, explicit cloud\u002Faccount\u002Fenvironment configuration, sign-in, connection diagnostics, or recovery from an authentication error.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fsetup\u002FSKILL.md",[],[110,39,115,116,117,118,119,120,121,122,123,124,125,126,127,128],"when","connection","error","sign","intelligence","configuration","use","process","diagnostics","environment","authentication","cloud","recovery","Bash",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":140,"publishedAt":52},"01M699WSR9EX55YY1WD9J22FEG","report-issue","Use when the user wants a Process Intelligence bug-report draft or support summary for a failed operation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Freport-issue\u002FSKILL.md",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[141,142,143,144,145,122,121,146,147,119,148,149,150,115,151],"report issue","report","issue","support","user","bug","summary","draft","operation","for","bug-report",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":52},"01M699WR26YQ9Q21KE6MJF5B2G","investigate-process","Use when a broad Process Mining business question, observed pattern or competing explanation needs investigation across analytical perspectives.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Finvestigate-process\u002FSKILL.md",[],[122,159,160,161,115,162,163,164,165,39,166,121,167,168,169],"investigate","investigate process","mining","process mining","investigation","perspectives","question","business","pattern","across","analytical",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":52},"01M699WP9SDG5ZR12P8VYNXKTN","derive-metric","Use when a requested measure is missing, a saved custom metric needs reuse, or an ephemeral formula or derived scalar is needed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fderive-metric\u002FSKILL.md",[],[177,178,39,121,179,180,181,182,183,115],"metric","derive metric","formula","missing","reuse","saved","custom",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":52},"01M699WMG5R8P6SMTDAS1TKF9E","compare-cohorts","Use when comparing process cohorts, departments, periods or before-and-after results under matched definitions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fcompare-cohorts\u002FSKILL.md",[],[191,192,115,121,122,193,39],"compare","compare cohorts","results",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":200,"publishedAt":52},"01M699WJWNVTMP9XK3NCJHV14D","analyze-variants","Use when investigating common or slow variants, repeated work, unusual paths, or a specific Process Mining case.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fanalyze-variants\u002FSKILL.md",[],[201,202,203,162,115,161,204,205,121,122,39,206,207],"analyze","variants","analyze variants","case","paths","work","common"]