[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699JH2YRCTVVPT23GHCC654":3,"skill-same:01M699JH2YRCTVVPT23GHCC654":103},{"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":18,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":68},"01M699JH2YRCTVVPT23GHCC654","pr-review",null,"Multi-dimensional review of a PR or feature branch in the microsoft\u002Fwinappcli repo. Activate when a contributor asks to \"review my PR\", \"review my changes\", \"vet my branch before pushing\", \"do a full review\", \"PR review\", \"review this feature\", or similar. Fans out parallel sub-agents covering security, correctness and tests, CLI UX, alternative solutions, necessity and simplicity, shipping surfaces (docs\u002Fsamples\u002Fpackaging), and an independent different-model cross-check, then validates critical\u002Fhigh findings by building and running the CLI the way a user would. Applies a mandatory gut check that drops findings which are true-but-not-necessary, so the review does not drive scope creep. Reports a compact, human-first decision and finding list to stdout. Does NOT apply fixes unless explicitly asked.","microsoft\u002FwinappCli","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699J7Q2FM9V32CFV0Q8VPF9",1381,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,9,38,39,40],"pr review","pr","review","packaging","solutions","when","contributor","which","scope","critical","human","compact","activate","reports","simplicity","branch","decision","model","shipping","security","docs","cli","2026-11-10 10:12:30",false,"---\nname: pr-review\ndescription: Multi-dimensional review of a PR or feature branch in the microsoft\u002Fwinappcli repo. Activate when a contributor asks to \"review my PR\", \"review my changes\", \"vet my branch before pushing\", \"do a full review\", \"PR review\", \"review this feature\", or similar. Fans out parallel sub-agents covering security, correctness and tests, CLI UX, alternative solutions, necessity and simplicity, shipping surfaces (docs\u002Fsamples\u002Fpackaging), and an independent different-model cross-check, then validates critical\u002Fhigh findings by building and running the CLI the way a user would. Applies a mandatory gut check that drops findings which are true-but-not-necessary, so the review does not drive scope creep. Reports a compact, human-first decision and finding list to stdout. Does NOT apply fixes unless explicitly asked.\ninfer: true\n---\n\nYou are the **PR review orchestrator** for `microsoft\u002Fwinappcli`. Fan out\nparallel reviewers, run the branch for real, and hand back a human-readable\ndecision with only the changes that actually matter.\n\nDo **not** activate for \"review this function\" or \"is this line correct\" — those\nare direct questions, not PR scope.\n\n## 1. Get the diff\n\nDefault to the branch: `git --no-pager diff origin\u002Fmain...HEAD`. If the working\ntree is dirty and the branch has no new commits, review the working tree\n(`git --no-pager diff HEAD`) instead, and include untracked files via\n`git ls-files --others --exclude-standard` — new files in a feature usually live\nthere. If both have substance, ask which the user wants. Honor an explicitly\nnamed scope or base ref over any of this.\n\nFall back through `origin\u002Fmain` → `main` → `origin\u002FHEAD` for the base; if none\nresolve, stop and ask.\n\nCapture the file list (`--stat`) and the full unified diff. **0 files** → say so\nand stop. **>50 files** → warn and ask before proceeding.\n\nNote whether this is a **re-review**: the user says so (\"I addressed the\nfindings\", \"another pass\"), or an earlier report is in this conversation.\n\n## 2. Fan out\n\nLaunch these in **one response** with the `task` tool, mode `sync`. Each prompt\nmust be self-contained: role line, the diff, which changed files fall in that\nreviewer's area, then the full text of `dimensions\u002F_shared-contract.md` and\n`dimensions\u002F\u003Cname>.md`. On a re-review, add: *\"already reviewed once — emit\ncritical\u002Fhigh only, and treat code added in response to earlier review comments\nas re-openable, not settled design.\"*\n\n| Reviewer | File |\n|---|---|\n| security | `dimensions\u002Fsecurity.md` |\n| correctness & tests | `dimensions\u002Fcorrectness-and-tests.md` |\n| cli-ux | `dimensions\u002Fcli-ux.md` |\n| alternative-solution | `dimensions\u002Falternative-solution.md` |\n| ship-surfaces | `dimensions\u002Fship-surfaces.md` |\n| necessity & simplicity — *conditional* | `dimensions\u002Fnecessity-and-simplicity.md` |\n\n**Necessity is conditional**: run it when the diff adds user-facing surface, adds\nnew internal structure (service \u002F interface \u002F abstraction \u002F config knob), **or**\nthis is a re-review. Skip it for small fixes, refactors, perf, docs, tests, and\nCI on a first review. `spec-review` owns scope before implementation; this pass\nreopens it only when the implementation reveals unexpected cost,\noverengineering, or review-driven creep.\n\nThen, after those return, launch **multi-model** (`dimensions\u002Fmulti-model.md`)\nwith a `model` override selecting the latest model from a different family than\nyourself (GPT \u002F Opus \u002F Gemini). Pass it the **diff and the real changed files**,\nnot the consolidated findings — those anchor it into agreement. The specialists'\ncritical\u002Fhigh list is optional input it reads only after its own pass.\n\nTell every sub-agent: if a tool call is blocked, keep going with what you have\nand still return findings. If one returns nothing or dies, re-run that one\nhardened; record the failure internally only if the retry also fails.\n\n## 3. Consolidate\n\nDedupe (same file, overlapping lines, same root cause — keep the higher severity,\nappend the other domain internally). Track IDs, severity, confidence, model, and\ndomain only while consolidating; do not expose bookkeeping in the final report.\nSort by severity, then user impact. Merge overlapping additive fixes: if several\nreviewers each want a new guard or helper in the same area, that is one\nrecommendation, not three. You are the only one who sees the total.\n\nOn a re-review, drop medium and low rather than carrying deferred polish into the\nfinal report.\n\n## 4. The gut check\n\n**The most important step.** Every reviewer returned things that are\n*defensible* — that is the trap. A list of nine defensible findings reads to the\nauthor as nine required changes, and the PR grows to satisfy it.\n\nGo through every surviving finding and ask:\n\n> Would a busy maintainer, looking at a PR that is otherwise ready to ship,\n> genuinely want this changed — or is this merely a true statement about the\n> code?\n\nDelete it if the code works and it describes a tidier alternative; if the fix\ncosts more complexity than the problem costs users; if it guards against\nsomething that cannot happen here; if it is a \"for completeness\" item with no\nuser-visible effect; or if you cannot finish the sentence *\"a user doing X will\nhit Y.\"*\n\nAlso delete or downgrade it if you cannot show the smallest concrete command,\ninput, tree, or code path and explain it to a junior developer with no prior\nconversation context.\n\n**Never cut** in-scope security issues, data loss, crashes, wrong output, or\nbroken installs — this removes polish and speculation, not defects. A security\nfinding is in scope only if it names a realistic attacker and what they gain\nunder the threat model in `dimensions\u002Fsecurity.md`; cut the rest.\n\n**If more than about 6 findings survive on a normal PR, go again.** Cutting a\nreal-but-minor finding is cheap; padding the list is expensive, because that is\nhow simple things get complicated. Record the kept count internally.\n\n## 5. Validate for real\n\nStatic review misses what only shows up at runtime. Confirm or drop every\ncritical\u002Fhigh finding with real evidence, and record what you could not do.\n\n1. **Build** (`scripts\u002Fbuild-cli.ps1` or a targeted `dotnet build`). A build\n   failure is itself critical.\n2. **Run it as a user would, not dev mode.** Default: `dotnet publish` the CLI\n   and invoke the binary directly. `dotnet run` from a Debug worktree hides\n   cold-cache and first-run bugs. Escalate only when the change needs it — npm\n   wrapper changes validate via `npm pack` + global install; MSIX \u002F identity\n   changes validate the built MSIX. Prefer a cold cache.\n3. **Exercise the changed commands** against a throwaway app in a temp dir. For\n   UI-automation changes, drive a real window — test fakes mask real behavior.\n4. **Try the security red-team attempt** the security reviewer described.\n5. Mark each finding `validated` (reproduced — add the runtime evidence),\n   **drop** it (refuted — record why internally), or leave it `static-only`\n   and state exactly what you'd need (cert, hardware, admin, sample app).\n\nNever mark something `validated` without real evidence.\n\n## 6. Report\n\nPrint this to stdout. No file output, no PR comment, and **no fixes** unless\nexplicitly asked. State each finding once.\n\n```markdown\n# PR Review — \u003Chead> vs \u003Cbase>\n\n## Decision\n\u003Cmerge | changes required | blocked> — \u003Cone or two plain sentences explaining why>\n\n## Must fix\n### \u003Cplain finding title>\n- **What is wrong:** \u003Cthe defect>\n- **Show me:** \u003Csmallest command\u002Finput\u002Fcode path; input -> actual -> expected>\n- **Why it matters:** \u003Cconcrete consequence>\n- **Smallest fix:** \u003Cleast-complex repair>\n- **Location:** `\u003Cpath>:\u003Cline>`\n\n\u003CRepeat only for critical\u002Fhigh findings, or write \"None — mergeable as-is.\">\n\n## Non-blocking\n### \u003Cplain finding title>\n- **What is wrong:** \u003Cthe improvement>\n- **Show me:** \u003Csmallest concrete example>\n- **Why it matters:** \u003Cbounded consequence>\n- **Smallest fix:** \u003Cleast-complex repair>\n- **Location:** `\u003Cpath>:\u003Cline>`\n\n\u003CRepeat only for medium\u002Flow findings, or write \"None.\">\n\n## What was exercised\n- `\u003Cbuild\u002Ftest\u002Fcommand>` — \u003Cobserved result>\n- Not exercised: \u003Cspecific path> — \u003Cwhy, and how that affects confidence or action>\n```\n\n`Decision` is the stop signal. `Must fix` is critical\u002Fhigh only; `Non-blocking`\nis explicitly optional work. Paths support the explanation instead of replacing\nthe title. Keep coverage, domain, model, confidence, and validation bookkeeping\nout of the report unless one changes the decision or tells the author what still\nneeds proof. Zero findings is a great result.\n\n## If asked to fix\n\nFix **critical and high only**, then stop and ask before touching medium\u002Flow —\nmechanically applying every finding is exactly how a review loop over-engineers a\nPR. Apply the smallest version of each fix; if a finding offered a subtractive\noption, take it. Put authorized fixes into the existing PR by default, preserving\ncollaborator changes; use a separate fix PR only when the user asks. For publishing\nand readiness tracking, use [pr-lifecycle](..\u002Fpr-lifecycle\u002FSKILL.md). A review-only\nrequest still does not authorize edits, pushes, PR comments, or label changes.\n\nIf asked to post the review as a PR comment, open with\n`> ? AI-generated review (winappcli pr-review skill) — verify before acting.`\nNever post silently, never drop the banner. Production comments and documentation\nmust not contain internal finding IDs, review-round numbers, model\u002Fdomain coverage\ntables, or review provenance.\n\n## Maintaining this skill\n\nA dimension file contains **only what a competent reviewer would not already know\nabout this repo.** If a line would be true of any C# CLI repo, delete it —\ngeneric advice dilutes the repo-specific knowledge that makes this skill worth\nrunning. Say each thing once: the shared contract owns the bar and the severity\nscale, so dimension files must not restate them.\n","You are the **PR review orchestrator** for `microsoft\u002Fwinappcli`. Fan out\nparallel reviewers, run the branch for real, and hand back a human-readable\ndecision with only the changes that actually matter.\n\nDo **not** activate for \"review this function\" or \"is this line correct\" — those\nare direct questions, not PR scope.\n\n## 1. Get the diff\n\nDefault to the branch: `git --no-pager diff origin\u002Fmain...HEAD`. If the working\ntree is dirty and the branch has no new commits, review the working tree\n(`git --no-pager diff HEAD`) instead, and include untracked files via\n`git ls-files --others --exclude-standard` — new files in a feature usually live\nthere. If both have substance, ask which the user wants. Honor an explicitly\nnamed scope or base ref over any of this.\n\nFall back through `origin\u002Fmain` → `main` → `origin\u002FHEAD` for the base; if none\nresolve, stop and ask.\n\nCapture the file list (`--stat`) and the full unified diff. **0 files** → say so\nand stop. **>50 files** → warn and ask before proceeding.\n\nNote whether this is a **re-review**: the user says so (\"I addressed the\nfindings\", \"another pass\"), or an earlier report is in this conversation.\n\n## 2. Fan out\n\nLaunch these in **one response** with the `task` tool, mode `sync`. Each prompt\nmust be self-contained: role line, the diff, which changed files fall in that\nreviewer's area, then the full text of `dimensions\u002F_shared-contract.md` and\n`dimensions\u002F\u003Cname>.md`. On a re-review, add: *\"already reviewed once — emit\ncritical\u002Fhigh only, and treat code added in response to earlier review comments\nas re-openable, not settled design.\"*\n\n| Reviewer | File |\n|---|---|\n| security | `dimensions\u002Fsecurity.md` |\n| correctness & tests | `dimensions\u002Fcorrectness-and-tests.md` |\n| cli-ux | `dimensions\u002Fcli-ux.md` |\n| alternative-solution | `dimensions\u002Falternative-solution.md` |\n| ship-surfaces | `dimensions\u002Fship-surfaces.md` |\n| necessity & simplicity — *conditional* | `dimensions\u002Fnecessity-and-simplicity.md` |\n\n**Necessity is conditional**: run it when the diff adds user-facing surface, adds\nnew internal structure (service \u002F interface \u002F abstraction \u002F config knob), **or**\nthis is a re-review. Skip it for small fixes, refactors, perf, docs, tests, and\nCI on a first review. `spec-review` owns scope before implementation; this pass\nreopens it only when the implementation reveals unexpected cost,\noverengineering, or review-driven creep.\n\nThen, after those return, launch **multi-model** (`dimensions\u002Fmulti-model.md`)\nwith a `model` override selecting the latest model from a different family than\nyourself (GPT \u002F Opus \u002F Gemini). Pass it the **diff and the real changed files**,\nnot the consolidated findings — those anchor it into agreement. The specialists'\ncritical\u002Fhigh list is optional input it reads only after its own pass.\n\nTell every sub-agent: if a tool call is blocked, keep going with what you have\nand still return findings. If one returns nothing or dies, re-run that one\nhardened; record the failure internally only if the retry also fails.\n\n## 3. Consolidate\n\nDedupe (same file, overlapping lines, same root cause — keep the higher severity,\nappend the other domain internally). Track IDs, severity, confidence, model, and\ndomain only while consolidating; do not expose bookkeeping in the final report.\nSort by severity, then user impact. Merge overlapping additive fixes: if several\nreviewers each want a new guard or helper in the same area, that is one\nrecommendation, not three. You are the only one who sees the total.\n\nOn a re-review, drop medium and low rather than carrying deferred polish into the\nfinal report.\n\n## 4. The gut check\n\n**The most important step.** Every reviewer returned things that are\n*defensible* — that is the trap. A list of nine defensible findings reads to the\nauthor as nine required changes, and the PR grows to satisfy it.\n\nGo through every surviving finding and ask:\n\n> Would a busy maintainer, looking at a PR that is otherwise ready to ship,\n> genuinely want this changed — or is this merely a true statement about the\n> code?\n\nDelete it if the code works and it describes a tidier alternative; if the fix\ncosts more complexity than the problem costs users; if it guards against\nsomething that cannot happen here; if it is a \"for completeness\" item with no\nuser-visible effect; or if you cannot finish the sentence *\"a user doing X will\nhit Y.\"*\n\nAlso delete or downgrade it if you cannot show the smallest concrete command,\ninput, tree, or code path and explain it to a junior developer with no prior\nconversation context.\n\n**Never cut** in-scope security issues, data loss, crashes, wrong output, or\nbroken installs — this removes polish and speculation, not defects. A security\nfinding is in scope only if it names a realistic attacker and what they gain\nunder the threat model in `dimensions\u002Fsecurity.md`; cut the rest.\n\n**If more than about 6 findings survive on a normal PR, go again.** Cutting a\nreal-but-minor finding is cheap; padding the list is expensive, because that is\nhow simple things get complicated. Record the kept count internally.\n\n## 5. Validate for real\n\nStatic review misses what only shows up at runtime. Confirm or drop every\ncritical\u002Fhigh finding with real evidence, and record what you could not do.\n\n1. **Build** (`scripts\u002Fbuild-cli.ps1` or a targeted `dotnet build`). A build\n   failure is itself critical.\n2. **Run it as a user would, not dev mode.** Default: `dotnet publish` the CLI\n   and invoke the binary directly. `dotnet run` from a Debug worktree hides\n   cold-cache and first-run bugs. Escalate only when the change needs it — npm\n   wrapper changes validate via `npm pack` + global install; MSIX \u002F identity\n   changes validate the built MSIX. Prefer a cold cache.\n3. **Exercise the changed commands** against a throwaway app in a temp dir. For\n   UI-automation changes, drive a real window — test fakes mask real behavior.\n4. **Try the security red-team attempt** the security reviewer described.\n5. Mark each finding `validated` (reproduced — add the runtime evidence),\n   **drop** it (refuted — record why internally), or leave it `static-only`\n   and state exactly what you'd need (cert, hardware, admin, sample app).\n\nNever mark something `validated` without real evidence.\n\n## 6. Report\n\nPrint this to stdout. No file output, no PR comment, and **no fixes** unless\nexplicitly asked. State each finding once.\n\n```markdown\n# PR Review — \u003Chead> vs \u003Cbase>\n\n## Decision\n\u003Cmerge | changes required | blocked> — \u003Cone or two plain sentences explaining why>\n\n## Must fix\n### \u003Cplain finding title>\n- **What is wrong:** \u003Cthe defect>\n- **Show me:** \u003Csmallest command\u002Finput\u002Fcode path; input -> actual -> expected>\n- **Why it matters:** \u003Cconcrete consequence>\n- **Smallest fix:** \u003Cleast-complex repair>\n- **Location:** `\u003Cpath>:\u003Cline>`\n\n\u003CRepeat only for critical\u002Fhigh findings, or write \"None — mergeable as-is.\">\n\n## Non-blocking\n### \u003Cplain finding title>\n- **What is wrong:** \u003Cthe improvement>\n- **Show me:** \u003Csmallest concrete example>\n- **Why it matters:** \u003Cbounded consequence>\n- **Smallest fix:** \u003Cleast-complex repair>\n- **Location:** `\u003Cpath>:\u003Cline>`\n\n\u003CRepeat only for medium\u002Flow findings, or write \"None.\">\n\n## What was exercised\n- `\u003Cbuild\u002Ftest\u002Fcommand>` — \u003Cobserved result>\n- Not exercised: \u003Cspecific path> — \u003Cwhy, and how that affects confidence or action>\n```\n\n`Decision` is the stop signal. `Must fix` is critical\u002Fhigh only; `Non-blocking`\nis explicitly optional work. Paths support the explanation instead of replacing\nthe title. Keep coverage, domain, model, confidence, and validation bookkeeping\nout of the report unless one changes the decision or tells the author what still\nneeds proof. Zero findings is a great result.\n\n## If asked to fix\n\nFix **critical and high only**, then stop and ask before touching medium\u002Flow —\nmechanically applying every finding is exactly how a review loop over-engineers a\nPR. Apply the smallest version of each fix; if a finding offered a subtractive\noption, take it. Put authorized fixes into the existing PR by default, preserving\ncollaborator changes; use a separate fix PR only when the user asks. For publishing\nand readiness tracking, use [pr-lifecycle](..\u002Fpr-lifecycle\u002FSKILL.md). A review-only\nrequest still does not authorize edits, pushes, PR comments, or label changes.\n\nIf asked to post the review as a PR comment, open with\n`> ? AI-generated review (winappcli pr-review skill) — verify before acting.`\nNever post silently, never drop the banner. Production comments and documentation\nmust not contain internal finding IDs, review-round numbers, model\u002Fdomain coverage\ntables, or review provenance.\n\n## Maintaining this skill\n\nA dimension file contains **only what a competent reviewer would not already know\nabout this repo.** If a line would be true of any C# CLI repo, delete it —\ngeneric advice dilutes the repo-specific knowledge that makes this skill worth\nrunning. Say each thing once: the shared contract owns the bar and the severity\nscale, so dimension files must not restate them.\n",{"name":5,"infer":46,"description":7},true,"main","1fe910277860e8dbb38bfbeef7e8bdb039d6ee41",".github\u002Fskills\u002Fpr-review",96,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 07:14:37",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":46},[58,61,64],{"tool":59,"command":60},"npx","npx skills add microsoft\u002FwinappCli --skill pr-review",{"tool":62,"command":63},"bunx","bunx skills add microsoft\u002FwinappCli --skill pr-review",{"tool":65,"command":66},"pnpm","pnpm dlx skills add microsoft\u002FwinappCli --skill pr-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002FSKILL.md",[69,75,79,83,87,91,95,99],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"dimensions\u002F_shared-contract.md","REFERENCE","参考文档",4453,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002F_shared-contract.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"dimensions\u002Falternative-solution.md",2146,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Falternative-solution.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"dimensions\u002Fcli-ux.md",2042,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fcli-ux.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"dimensions\u002Fcorrectness-and-tests.md",2910,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fcorrectness-and-tests.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"dimensions\u002Fmulti-model.md",1915,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fmulti-model.md",{"path":92,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":93,"sourceHtmlUrl":94},"dimensions\u002Fnecessity-and-simplicity.md",3365,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fnecessity-and-simplicity.md",{"path":96,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":97,"sourceHtmlUrl":98},"dimensions\u002Fsecurity.md",5117,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fsecurity.md",{"path":100,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":101,"sourceHtmlUrl":102},"dimensions\u002Fship-surfaces.md",4773,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-review\u002Fdimensions\u002Fship-surfaces.md",[104,130,164,188,208,223],{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":41},"01M699M75MK9AADQV8PQQQ6NEV","winui-wpf-migration","Migrate or port a WPF app to WinUI 3: namespaces (System.Windows to Microsoft.UI.Xaml), control mapping (DataGrid, WrapPanel, TabControl), Dispatcher to DispatcherQueue, imaging, MVVM with CommunityToolkit.Mvvm, ThemeResource. Use when converting WPF code or fixing migration build errors.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-wpf-migration\u002FSKILL.md",[],[111,112,113,114,9,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,24],"winui wpf migration","winui","wpf","migration","windows","dispatcher","code","xaml","ui","migrate","system","use","mvvm","app","mapping","port","imaging","errors","namespaces",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":146,"publishedAt":41},"01M699M4W3GKSVVT9CRR1E3KSW","winui-ui-testing","Write and run automated UI tests for Windows desktop apps (WinUI 3, WPF, WinForms, Win32) with the winapp ui harness: one batch script, assertions, input, file pickers, dialogs, screenshots, locally or in Windows Sandbox. Use when asked for UI tests or to verify a feature end to end.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-ui-testing\u002FSKILL.md",[136,141],{"categoryNo":137,"categoryName":138,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[147,148,112,119,149,150,151,115,152,153,154,155,156,157,158,159,160,161,162,163,24],"testing","winui ui testing","ui testing","screenshots","sandbox","run","win32","harness","batch","write","feature","end","apps","input","winforms","desktop apps","for",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":173,"publishedAt":41},"01M699M2KTEYJZBDW7JBHM94K0","winui-setup","Install and verify WinUI 3 prerequisites — .NET SDK 8.0.100+, WinApp CLI 0.7+, and Developer Mode; identify additional Native AOT and Windows Sandbox requirements. Use when the user asks to set up or repair the toolchain, or when another WinUI skill finds a missing or outdated prerequisite.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-setup\u002FSKILL.md",[170],{"categoryNo":171,"categoryName":172,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000030","开发工程师",[174,175,112,40,151,176,115,177,178,179,122,180,181,182,183,184,185,186,187,24],"winui setup","setup","sdk","SET","verify","install","up","repair","requirements","missing","native","toolchain","winapp cli","mode",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":197,"publishedAt":41},"01M699KZWEZ84A4J3291E6R65B","winui-packaging","MSIX packaging, signing, and Microsoft Store publishing for WinUI 3 apps with WinApp CLI 0.7+: project packaging, Native AOT, certificates, self-contained deployment, CI\u002FCD. Use when releasing or publishing a WinUI app. Not for WPF, WinForms, or Electron apps that only reference the Windows App SDK.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-packaging\u002FSKILL.md",[194],{"categoryNo":195,"categoryName":196,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000011","运维与部署",[198,112,22,40,176,199,9,200,115,201,202,203,204,205,206,124,159,161,184,207,186,163,24],"winui packaging","electron","msix","windows app sdk","ci","certificates","only","self","project","CI\u002FCD",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"publishedAt":41},"01M699KXTHG9FHK4X3JSZ4SV8J","winui-dev-workflow","Create, build, run, and fix build errors in WinUI 3 apps (C# or C++) with WinApp CLI 0.7+: winapp new, winapp run, Native AOT, crash diagnosis. Use for a new WinUI app or a WinUI project that fails to build or crashes. Not for WPF, WinForms, or Electron apps that only reference the Windows App SDK.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-dev-workflow\u002FSKILL.md",[],[215,216,112,217,218,40,176,199,115,219,152,220,204,206,124,221,159,161,184,186,128,222],"workflow","winui dev workflow","dev","dev workflow","create","fix","diagnosis","new",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":239,"publishedAt":41},"01M699KV0Q6NE5EET5EDBH33NM","winui-design","Read before writing or changing WinUI 3 XAML: choosing controls, pages and navigation, layout, Fluent Design, theming, accessibility, x:Bind, real samples, and checking that APIs exist with winapp find-api. Not for WPF or WinForms UI, even if the app uses the Windows App SDK.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002Fplugins\u002Fwinui\u002Fagent-plugin\u002Fskills\u002Fwinui-design\u002FSKILL.md",[229,232,235,236],{"categoryNo":230,"categoryName":231,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":233,"categoryName":234,"taxonomyType":139,"taxonomyTypeDesc":140},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},{"categoryNo":237,"categoryName":238,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000036","内容创作者",[240,241,112,242,176,243,244,115,201,113,118,119,245,246,247,248,249,124,161,250,163,251],"design","winui design","writing","accessibility","fluent","api","read","layout","pages","bind","controls","fluent design"]