[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699JES2DSDSE2JKD3SP1XW1":3,"skill-same:01M699JES2DSDSE2JKD3SP1XW1":67},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":66},"01M699JES2DSDSE2JKD3SP1XW1","pr-lifecycle",null,"Prepare, present, and finish a contributor PR in microsoft\u002Fwinappcli. Activate for \"create a PR\", \"prepare this PR\", \"get this PR ready for review\", or \"take this PR through readiness\". Keeps fixes in the existing PR, communicates evidence, and tracks current-head readiness separately from human approval. A body-only draft or review-only request does not authorize edits, posting, labels, or merge. Never merges or enables auto-merge.","microsoft\u002FwinappCli","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699J7Q2FM9V32CFV0Q8VPF9",1380,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-lifecycle\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,9],"pr lifecycle","pr","lifecycle","ready","body","contributor","request","labels","present","get","human","activate","take","finish","review","only","never","auto","create","merge","2026-11-10 10:12:30",false,"---\nname: pr-lifecycle\ndescription: Prepare, present, and finish a contributor PR in microsoft\u002Fwinappcli. Activate for \"create a PR\", \"prepare this PR\", \"get this PR ready for review\", or \"take this PR through readiness\". Keeps fixes in the existing PR, communicates evidence, and tracks current-head readiness separately from human approval. A body-only draft or review-only request does not authorize edits, posting, labels, or merge. Never merges or enables auto-merge.\ninfer: true\n---\n\n# PR lifecycle: Prepare, Present, Finish\n\nUse this for work on this repository, not as a shipped `winapp` plugin skill.\nThe outcome is a clear PR and an honest readiness state, not a merge.\n\n## Authority and repository policy\n\n- Establish the requested scope first. \"Draft a PR body\" returns text only;\n  \"review this PR\" returns findings only. Neither authorizes changing code,\n  pushing, posting, requesting reviews, or changing labels. A request to create\n  or take a PR through readiness authorizes the necessary in-scope work, not\n  unrelated changes or merging. Confirm any additional authority you need.\n- Read [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md), the\n  [PR template](..\u002F..\u002FPULL_REQUEST_TEMPLATE.md), affected workflow definitions in\n  `.github\\workflows`, and applicable `.pipelines` instructions. Live branch\n  protection\u002Frulesets are the source of truth for required checks and approvals;\n  do not freeze their names or counts here.\n- [pr-review](..\u002Fpr-review\u002FSKILL.md) owns independent, practical review of\n  correctness, compatibility and performance. Use it for a full feature review;\n  keep a narrow docs\u002Ffix review proportional rather than copying its entire\n  orchestration. [spec-review](..\u002Fspec-review\u002FSKILL.md) is for unresolved design\n  questions before implementation, not another mandatory post-code ceremony.\n- Fix findings **in the existing PR** by default. Create a follow-up fix PR only\n  when the user asks. Preserve the review-only default of `pr-review`.\n- Use the host's `create_pull_request`, `update_pull_request`, and\n  `reply_and_resolve_review_thread` tools when available; obey their contracts\n  rather than substituting shell commands. Other GitHub reads\u002Factions may use\n  `gh`. Never merge, enable auto-merge, bypass protection, dismiss a human\n  changes-request review, or manufacture an approval.\n\n## Prepare\n\n1. **Identify the real comparison.** Read the live PR (if it exists): repository,\n   number, state, head repository\u002Fref\u002FSHA, base ref\u002FSHA, draft state, checks,\n   reviews and mergeability. Inspect local status, tracking refs and the full\n   diff including relevant untracked files. Fetch the actual head and base;\n   do not assume the local branch or `origin\u002Fmain` is current. Record immutable\n   head\u002Fbase SHAs for the assessment.\n2. **Preserve other work.** Do not stage unrelated files, delete scratch files,\n   discard a dirty tree, or overwrite collaborator commits. If the remote head\n   differs from your expected head, inspect it before continuing; stop and\n   coordinate overlapping edits. Prefer a normal non-rewriting update. Rewrite\n   only with permission and an explicit expected-SHA lease\n   (`--force-with-lease=\u003Cref>:\u003Cexpected-sha>`); a failed lease means re-inspect,\n   not force harder.\n3. **Respect stacks.** Review against the actual parent branch, not the entire\n   stack against main. Use the available native stack skill\u002Ftool to synchronize\n   parents and propagate updates. Check the parent and ultimate main as\n   appropriate to repository policy; do not blindly retarget to main or merge\n   main into a child. For an ordinary PR, incorporate required base updates\n   safely and resolve conflicts before assessing readiness.\n4. **Review and repair.** Get independent review of the actual final diff.\n   Review concrete user paths, supported released compatibility contracts and\n   meaningful performance risks, not speculative edge cases. Fix only findings\n   that meet \"What blocks a PR\" in `AGENTS.md`, with regression tests where\n   applicable, and handle everything else as \"Addressing review feedback\"\n   describes (one-line decline, scope guard, at most two review-and-fix rounds).\n   Explain false positives with\n   evidence; do not silently mark them addressed. A prior review remains useful\n   only if its SHA is recorded and every subsequent delta is reviewed, or\n   range-equivalence is demonstrated. A rebase alone is not proof of equivalence.\n5. **Validate the changed behavior.** Run the smallest relevant existing tests,\n   builds and user-path checks required by repository instructions. Update only\n   affected documentation. Record exact commands and observed outcomes,\n   including limitations. For contributor Markdown-only changes, check\n   frontmatter, links\u002Fpaths and Markdown plus applicable docs tooling; no full\n   NativeAOT build is needed unless that tooling requires it.\n\nDo not call a local test pass a CI pass, or call your own inspection independent\nreview. An initial independent assessment needed to evaluate the work is part of\npreparation. Do not invent edits to elicit a favorable review; distinguish that\nassessment from waiting for re-review of feedback already addressed.\n\n## Present\n\nUse a short, outcome-oriented title and the repository PR template. Keep its\napplicable headings; mark non-applicable sections honestly. The body describes\nthe **final feature**, not each round of agent activity:\n\n- Explain the plain-language problem and what users can now do.\n- Show the smallest concrete before\u002Fafter command, input or interaction and\n  actual result. Distinguish observed output from an illustrative example.\n- Include focused validation evidence, honest limitations, and only real\n  compatibility, dependency or performance tradeoffs. For compatibility, use\n  the published-contract test in `AGENTS.md`.\n- For visual changes, capture actual before\u002Fafter screenshots. For interactions,\n  use a short recording showing the relevant behavior. For CLI changes, capture\n  the terminal with `scripts\\capture-terminal.ps1` (a screenshot, or `-Video`\n  for multi-step flows); paste text only when capture isn't possible.\n  Documentation-only work needs no screenshots.\n  Performance claims need benchmark conditions (build, hardware, workload,\n  cache state and baseline) and measured results.\n- Never fabricate\u002Fdecorate evidence or include secrets, personal data or other\n  sensitive content. Use `github-pr-media` for uploads when available and follow\n  its permissions. If evidence cannot be captured, state the limitation.\n- Omit file inventories, agent transcripts, internal finding IDs, review-round\n  logs and model coverage. Reviewers should not need the agent conversation.\n\nBefore editing an existing body, read its live content. Preserve human edits and\nuse the update tool's optimistic guard (`base_sha` when supplied). On a stale\nedit, re-read and reconcile instead of retrying an old full-body replacement.\nIf the host has no guard, re-read immediately before a minimal update and stop\non conflicting edits.\n\nUse the lifecycle label as the PR's readiness signal. Do not post or maintain\nautomated lifecycle status comments or round-by-round progress comments.\nNecessary replies to review feedback are still required; they are not status\nupdates.\n\nKeep operational details in a durable session checkpoint: PR URL\u002Fnumber,\nhead\u002Fbase SHAs (and main\u002Fparent when relevant), review coverage, pending gates,\nblocker\u002Fowner\u002Fnext step, and the configured wakeup or resume action. Do not commit\nthese checkpoints or copy their history into the feature body. Ask the author\ndirectly when their input is needed.\n\n## Finish\n\n### Read the complete live discussion\n\nRead **all pages** of inline review threads, including replies, and all\ntop-level review bodies and issue comments. Inspect the current PR body for\nactionable requests too. Do not infer \"no findings\" from a summary, the last\nreview, unresolved-thread count alone, or the first 100 results.\n\nReply to each actionable thread with the fix\u002Fevidence or a reasoned disagreement\n**before** resolving it. Use `reply_and_resolve_review_thread` when available.\nFor actionable findings in a review body or top-level comment, answer in the\nappropriate discussion surface and record the disposition in the session\ncheckpoint. Keep substantive disagreement and its supporting evidence explicit\nin that reply until reassessed; do not present an unaddressed defect as a resolved\ndisagreement.\n\nNever dismiss a human's changes request yourself. After addressing it, re-request\nthat reviewer and record the pending re-review and owner in the session checkpoint.\nWaiting for that reassessment is not an agent blocker: if the agent has addressed\nthe feedback and completed the other technical gates, the PR is ready for review\neven while GitHub still shows the earlier `CHANGES_REQUESTED` review.\nDo not repeatedly request Copilot reviews merely to obtain favorable wording.\nDistinguish:\n\n| Evidence | Meaning |\n|----------|---------|\n| Current-head Copilot review with zero actionable findings | Technical review evidence, not a human approval |\n| Formal `APPROVED` review | An approval event; still check author, SHA and repository rules |\n| Review or re-review pending after feedback is addressed | Use `ready-for-review` once the other technical gates pass; approval remains pending |\n| Unaddressed defect or substantive concern | Keep preparing if the agent can resolve it; block only when the agent cannot proceed without help or author input |\n\nThe absence of the exact words \"Approval recommended\" is not a defect. Do not\nmake fake changes, rubber-stamp, or argue an automated reviewer into approval.\n\n### Verify checks and integration\n\nRequired CI must be completed and green for the **latest head** and the\nintegration\u002Fmerge commit where applicable, not an older successful run. Inspect\nlive required-check policy as well as actual runs: missing required checks are\npending, never a pass. Accept neutral\u002Fskipped only where expected under\nrepository policy. Do not treat an inaccessible policy or unknown mergeability\nas verified readiness.\n\nFor failure, inspect the failing job and logs first. Retry only a bounded number\nof times when evidence shows a transient infrastructure failure; record why.\nFix deterministic failures. Never weaken assertions, bypass checks, or dismiss\nfailures as \"environmental\" without investigation and a concrete resolution.\n\nUse bounded waits\u002Fbackoff rather than a tight polling loop (for example, inspect\nafter 30, 60 and 120 seconds, then checkpoint). Prefer notifications or an\navailable supported wakeup mechanism. This skill **cannot wake an idle agent**.\nIf no mechanism is configured, say \"Not actively monitoring\" and name the pending\ngate and resume action. Do not claim to be watching indefinitely.\nMarking a PR ready for review does not end follow-through on a requested\nre-review: keep configured notifications or wakeups active while that feedback\nis pending, and address any new actionable findings.\n\n### Set exactly one lifecycle label\n\nFor an open PR managed by this workflow, the following labels are mutually\nexclusive. Preserve unrelated labels.\n\n| Label | Apply when |\n|-------|------------|\n| `agent-preparing` | Agent work remains: addressing feedback, completing validation\u002FCI, or obtaining the initial independent assessment |\n| `agent-blocked` | The agent cannot finish addressing feedback or fixing CI with the available access, tools or information, or needs author input; name the concrete blocker, owner and next step |\n| `ready-for-review` | Agent work and technical checks are complete for the current head\u002Fbase; waiting for review or re-review is normal, **not** human approval or merge permission |\n\nChoose `agent-blocked` based on the agent's inability to proceed, not a review\nstatus. Fixable findings, fixable CI failures and ordinary CI waits mean\n`agent-preparing`. After feedback has a fix or an evidence-backed disposition,\nwaiting for reviewer acceptance or reassessment means `ready-for-review` if the\nother technical gates pass. Keep pending reviews and merge-blocking approval\nrequirements in the session checkpoint; do not dismiss them or claim approval.\n\nBefore **each label transition**, fetch a live snapshot. Before ready, confirm:\nindependent final-diff coverage and a fix or evidence-backed disposition for each\nactionable finding, required CI completed successfully, required base\u002Fstack\nintegration current, and no merge conflicts. Re-fetch head\u002Fbase (and relevant\nparent\u002Fmain), discussion and checks after assessment. If any changed, reassess\nrather than applying a stale result. Unknown conflict state means not ready.\n\nReplace the other lifecycle labels with the selected one. When adopting this\nPR, also remove legacy `pr-review-done` if present; it is not a readiness signal\nfor this workflow. Create missing labels only with authorization. Do not relabel\nunrelated PRs or redefine\u002Fdelete their labels. If permissions prevent a change,\nreport the intended state and failed action; never claim a label was applied.\nRe-read labels and head\u002Fbase after writing; if a race invalidated readiness,\nremove the ready label and reassess.\n\nA new commit, actionable finding or conflict invalidates readiness; an unrelated\ncomment does not. Base\u002Fmain movement requires appropriate integration and\nrevalidation, not a promise the PR stays permanently clean. When next invoked on\na merged\u002Fclosed PR, remove active lifecycle labels and stop; do not reopen it.\n\n### Useful read-only GitHub commands\n\nSet `$repo` and `$number` from the actual PR, not from an unrelated checkout.\nThese reads supplement, not replace, the complete discussion and policy checks:\n\n```powershell\ngh pr view $number --repo $repo --json url,state,headRefOid,headRefName,headRepository,baseRefName,baseRefOid,isDraft,mergeable,mergeStateStatus,reviewDecision,body,labels,statusCheckRollup\ngh pr checks $number --repo $repo --required\ngh api --paginate \"repos\u002F$repo\u002Fpulls\u002F$number\u002Freviews\"\ngh api --paginate \"repos\u002F$repo\u002Fissues\u002F$number\u002Fcomments\"\ngh api --paginate \"repos\u002F$repo\u002Fpulls\u002F$number\u002Fcomments\"\n# URL-encode the actual base ref as a single path segment for this endpoint.\ngh api \"repos\u002F$repo\u002Frules\u002Fbranches\u002F$([Uri]::EscapeDataString($baseRef))\"\n# For a failing GitHub Actions run; use its provider's logs for external CI.\ngh run view $runId --repo $repo --log-failed\n```\n\nREST pull comments do not expose thread resolution state. Use a GraphQL\n`pullRequest.reviewThreads(first:100, after:...)` query with `pageInfo` and\n`comments(first:100, after:...)`, fetching every thread page **and every nested\ncomment page**. Capture each thread `id` and comment `databaseId` for the reply\ntool. If GraphQL\u002FSSO access is unavailable, report the missing thread assessment\nas a gate; a REST-only partial read is not a clean review.\n\nEnd with the PR link, actual state, and any remaining blocker\u002Fnext action.\nSeparate \"technically ready\" from \"approved\" and \"merged\"; never imply either\nof the latter from a lifecycle label.\n","# PR lifecycle: Prepare, Present, Finish\n\nUse this for work on this repository, not as a shipped `winapp` plugin skill.\nThe outcome is a clear PR and an honest readiness state, not a merge.\n\n## Authority and repository policy\n\n- Establish the requested scope first. \"Draft a PR body\" returns text only;\n  \"review this PR\" returns findings only. Neither authorizes changing code,\n  pushing, posting, requesting reviews, or changing labels. A request to create\n  or take a PR through readiness authorizes the necessary in-scope work, not\n  unrelated changes or merging. Confirm any additional authority you need.\n- Read [AGENTS.md](..\u002F..\u002F..\u002FAGENTS.md), the\n  [PR template](..\u002F..\u002FPULL_REQUEST_TEMPLATE.md), affected workflow definitions in\n  `.github\\workflows`, and applicable `.pipelines` instructions. Live branch\n  protection\u002Frulesets are the source of truth for required checks and approvals;\n  do not freeze their names or counts here.\n- [pr-review](..\u002Fpr-review\u002FSKILL.md) owns independent, practical review of\n  correctness, compatibility and performance. Use it for a full feature review;\n  keep a narrow docs\u002Ffix review proportional rather than copying its entire\n  orchestration. [spec-review](..\u002Fspec-review\u002FSKILL.md) is for unresolved design\n  questions before implementation, not another mandatory post-code ceremony.\n- Fix findings **in the existing PR** by default. Create a follow-up fix PR only\n  when the user asks. Preserve the review-only default of `pr-review`.\n- Use the host's `create_pull_request`, `update_pull_request`, and\n  `reply_and_resolve_review_thread` tools when available; obey their contracts\n  rather than substituting shell commands. Other GitHub reads\u002Factions may use\n  `gh`. Never merge, enable auto-merge, bypass protection, dismiss a human\n  changes-request review, or manufacture an approval.\n\n## Prepare\n\n1. **Identify the real comparison.** Read the live PR (if it exists): repository,\n   number, state, head repository\u002Fref\u002FSHA, base ref\u002FSHA, draft state, checks,\n   reviews and mergeability. Inspect local status, tracking refs and the full\n   diff including relevant untracked files. Fetch the actual head and base;\n   do not assume the local branch or `origin\u002Fmain` is current. Record immutable\n   head\u002Fbase SHAs for the assessment.\n2. **Preserve other work.** Do not stage unrelated files, delete scratch files,\n   discard a dirty tree, or overwrite collaborator commits. If the remote head\n   differs from your expected head, inspect it before continuing; stop and\n   coordinate overlapping edits. Prefer a normal non-rewriting update. Rewrite\n   only with permission and an explicit expected-SHA lease\n   (`--force-with-lease=\u003Cref>:\u003Cexpected-sha>`); a failed lease means re-inspect,\n   not force harder.\n3. **Respect stacks.** Review against the actual parent branch, not the entire\n   stack against main. Use the available native stack skill\u002Ftool to synchronize\n   parents and propagate updates. Check the parent and ultimate main as\n   appropriate to repository policy; do not blindly retarget to main or merge\n   main into a child. For an ordinary PR, incorporate required base updates\n   safely and resolve conflicts before assessing readiness.\n4. **Review and repair.** Get independent review of the actual final diff.\n   Review concrete user paths, supported released compatibility contracts and\n   meaningful performance risks, not speculative edge cases. Fix only findings\n   that meet \"What blocks a PR\" in `AGENTS.md`, with regression tests where\n   applicable, and handle everything else as \"Addressing review feedback\"\n   describes (one-line decline, scope guard, at most two review-and-fix rounds).\n   Explain false positives with\n   evidence; do not silently mark them addressed. A prior review remains useful\n   only if its SHA is recorded and every subsequent delta is reviewed, or\n   range-equivalence is demonstrated. A rebase alone is not proof of equivalence.\n5. **Validate the changed behavior.** Run the smallest relevant existing tests,\n   builds and user-path checks required by repository instructions. Update only\n   affected documentation. Record exact commands and observed outcomes,\n   including limitations. For contributor Markdown-only changes, check\n   frontmatter, links\u002Fpaths and Markdown plus applicable docs tooling; no full\n   NativeAOT build is needed unless that tooling requires it.\n\nDo not call a local test pass a CI pass, or call your own inspection independent\nreview. An initial independent assessment needed to evaluate the work is part of\npreparation. Do not invent edits to elicit a favorable review; distinguish that\nassessment from waiting for re-review of feedback already addressed.\n\n## Present\n\nUse a short, outcome-oriented title and the repository PR template. Keep its\napplicable headings; mark non-applicable sections honestly. The body describes\nthe **final feature**, not each round of agent activity:\n\n- Explain the plain-language problem and what users can now do.\n- Show the smallest concrete before\u002Fafter command, input or interaction and\n  actual result. Distinguish observed output from an illustrative example.\n- Include focused validation evidence, honest limitations, and only real\n  compatibility, dependency or performance tradeoffs. For compatibility, use\n  the published-contract test in `AGENTS.md`.\n- For visual changes, capture actual before\u002Fafter screenshots. For interactions,\n  use a short recording showing the relevant behavior. For CLI changes, capture\n  the terminal with `scripts\\capture-terminal.ps1` (a screenshot, or `-Video`\n  for multi-step flows); paste text only when capture isn't possible.\n  Documentation-only work needs no screenshots.\n  Performance claims need benchmark conditions (build, hardware, workload,\n  cache state and baseline) and measured results.\n- Never fabricate\u002Fdecorate evidence or include secrets, personal data or other\n  sensitive content. Use `github-pr-media` for uploads when available and follow\n  its permissions. If evidence cannot be captured, state the limitation.\n- Omit file inventories, agent transcripts, internal finding IDs, review-round\n  logs and model coverage. Reviewers should not need the agent conversation.\n\nBefore editing an existing body, read its live content. Preserve human edits and\nuse the update tool's optimistic guard (`base_sha` when supplied). On a stale\nedit, re-read and reconcile instead of retrying an old full-body replacement.\nIf the host has no guard, re-read immediately before a minimal update and stop\non conflicting edits.\n\nUse the lifecycle label as the PR's readiness signal. Do not post or maintain\nautomated lifecycle status comments or round-by-round progress comments.\nNecessary replies to review feedback are still required; they are not status\nupdates.\n\nKeep operational details in a durable session checkpoint: PR URL\u002Fnumber,\nhead\u002Fbase SHAs (and main\u002Fparent when relevant), review coverage, pending gates,\nblocker\u002Fowner\u002Fnext step, and the configured wakeup or resume action. Do not commit\nthese checkpoints or copy their history into the feature body. Ask the author\ndirectly when their input is needed.\n\n## Finish\n\n### Read the complete live discussion\n\nRead **all pages** of inline review threads, including replies, and all\ntop-level review bodies and issue comments. Inspect the current PR body for\nactionable requests too. Do not infer \"no findings\" from a summary, the last\nreview, unresolved-thread count alone, or the first 100 results.\n\nReply to each actionable thread with the fix\u002Fevidence or a reasoned disagreement\n**before** resolving it. Use `reply_and_resolve_review_thread` when available.\nFor actionable findings in a review body or top-level comment, answer in the\nappropriate discussion surface and record the disposition in the session\ncheckpoint. Keep substantive disagreement and its supporting evidence explicit\nin that reply until reassessed; do not present an unaddressed defect as a resolved\ndisagreement.\n\nNever dismiss a human's changes request yourself. After addressing it, re-request\nthat reviewer and record the pending re-review and owner in the session checkpoint.\nWaiting for that reassessment is not an agent blocker: if the agent has addressed\nthe feedback and completed the other technical gates, the PR is ready for review\neven while GitHub still shows the earlier `CHANGES_REQUESTED` review.\nDo not repeatedly request Copilot reviews merely to obtain favorable wording.\nDistinguish:\n\n| Evidence | Meaning |\n|----------|---------|\n| Current-head Copilot review with zero actionable findings | Technical review evidence, not a human approval |\n| Formal `APPROVED` review | An approval event; still check author, SHA and repository rules |\n| Review or re-review pending after feedback is addressed | Use `ready-for-review` once the other technical gates pass; approval remains pending |\n| Unaddressed defect or substantive concern | Keep preparing if the agent can resolve it; block only when the agent cannot proceed without help or author input |\n\nThe absence of the exact words \"Approval recommended\" is not a defect. Do not\nmake fake changes, rubber-stamp, or argue an automated reviewer into approval.\n\n### Verify checks and integration\n\nRequired CI must be completed and green for the **latest head** and the\nintegration\u002Fmerge commit where applicable, not an older successful run. Inspect\nlive required-check policy as well as actual runs: missing required checks are\npending, never a pass. Accept neutral\u002Fskipped only where expected under\nrepository policy. Do not treat an inaccessible policy or unknown mergeability\nas verified readiness.\n\nFor failure, inspect the failing job and logs first. Retry only a bounded number\nof times when evidence shows a transient infrastructure failure; record why.\nFix deterministic failures. Never weaken assertions, bypass checks, or dismiss\nfailures as \"environmental\" without investigation and a concrete resolution.\n\nUse bounded waits\u002Fbackoff rather than a tight polling loop (for example, inspect\nafter 30, 60 and 120 seconds, then checkpoint). Prefer notifications or an\navailable supported wakeup mechanism. This skill **cannot wake an idle agent**.\nIf no mechanism is configured, say \"Not actively monitoring\" and name the pending\ngate and resume action. Do not claim to be watching indefinitely.\nMarking a PR ready for review does not end follow-through on a requested\nre-review: keep configured notifications or wakeups active while that feedback\nis pending, and address any new actionable findings.\n\n### Set exactly one lifecycle label\n\nFor an open PR managed by this workflow, the following labels are mutually\nexclusive. Preserve unrelated labels.\n\n| Label | Apply when |\n|-------|------------|\n| `agent-preparing` | Agent work remains: addressing feedback, completing validation\u002FCI, or obtaining the initial independent assessment |\n| `agent-blocked` | The agent cannot finish addressing feedback or fixing CI with the available access, tools or information, or needs author input; name the concrete blocker, owner and next step |\n| `ready-for-review` | Agent work and technical checks are complete for the current head\u002Fbase; waiting for review or re-review is normal, **not** human approval or merge permission |\n\nChoose `agent-blocked` based on the agent's inability to proceed, not a review\nstatus. Fixable findings, fixable CI failures and ordinary CI waits mean\n`agent-preparing`. After feedback has a fix or an evidence-backed disposition,\nwaiting for reviewer acceptance or reassessment means `ready-for-review` if the\nother technical gates pass. Keep pending reviews and merge-blocking approval\nrequirements in the session checkpoint; do not dismiss them or claim approval.\n\nBefore **each label transition**, fetch a live snapshot. Before ready, confirm:\nindependent final-diff coverage and a fix or evidence-backed disposition for each\nactionable finding, required CI completed successfully, required base\u002Fstack\nintegration current, and no merge conflicts. Re-fetch head\u002Fbase (and relevant\nparent\u002Fmain), discussion and checks after assessment. If any changed, reassess\nrather than applying a stale result. Unknown conflict state means not ready.\n\nReplace the other lifecycle labels with the selected one. When adopting this\nPR, also remove legacy `pr-review-done` if present; it is not a readiness signal\nfor this workflow. Create missing labels only with authorization. Do not relabel\nunrelated PRs or redefine\u002Fdelete their labels. If permissions prevent a change,\nreport the intended state and failed action; never claim a label was applied.\nRe-read labels and head\u002Fbase after writing; if a race invalidated readiness,\nremove the ready label and reassess.\n\nA new commit, actionable finding or conflict invalidates readiness; an unrelated\ncomment does not. Base\u002Fmain movement requires appropriate integration and\nrevalidation, not a promise the PR stays permanently clean. When next invoked on\na merged\u002Fclosed PR, remove active lifecycle labels and stop; do not reopen it.\n\n### Useful read-only GitHub commands\n\nSet `$repo` and `$number` from the actual PR, not from an unrelated checkout.\nThese reads supplement, not replace, the complete discussion and policy checks:\n\n```powershell\ngh pr view $number --repo $repo --json url,state,headRefOid,headRefName,headRepository,baseRefName,baseRefOid,isDraft,mergeable,mergeStateStatus,reviewDecision,body,labels,statusCheckRollup\ngh pr checks $number --repo $repo --required\ngh api --paginate \"repos\u002F$repo\u002Fpulls\u002F$number\u002Freviews\"\ngh api --paginate \"repos\u002F$repo\u002Fissues\u002F$number\u002Fcomments\"\ngh api --paginate \"repos\u002F$repo\u002Fpulls\u002F$number\u002Fcomments\"\n# URL-encode the actual base ref as a single path segment for this endpoint.\ngh api \"repos\u002F$repo\u002Frules\u002Fbranches\u002F$([Uri]::EscapeDataString($baseRef))\"\n# For a failing GitHub Actions run; use its provider's logs for external CI.\ngh run view $runId --repo $repo --log-failed\n```\n\nREST pull comments do not expose thread resolution state. Use a GraphQL\n`pullRequest.reviewThreads(first:100, after:...)` query with `pageInfo` and\n`comments(first:100, after:...)`, fetching every thread page **and every nested\ncomment page**. Capture each thread `id` and comment `databaseId` for the reply\ntool. If GraphQL\u002FSSO access is unavailable, report the missing thread assessment\nas a gate; a REST-only partial read is not a clean review.\n\nEnd with the PR link, actual state, and any remaining blocker\u002Fnext action.\nSeparate \"technically ready\" from \"approved\" and \"merged\"; never imply either\nof the latter from a lifecycle label.\n",{"name":5,"infer":44,"description":7},true,"main","1fe910277860e8dbb38bfbeef7e8bdb039d6ee41",".github\u002Fskills\u002Fpr-lifecycle",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-13 02:57:36",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":44},[56,59,62],{"tool":57,"command":58},"npx","npx skills add microsoft\u002FwinappCli --skill pr-lifecycle",{"tool":60,"command":61},"bunx","bunx skills add microsoft\u002FwinappCli --skill pr-lifecycle",{"tool":63,"command":64},"pnpm","pnpm dlx skills add microsoft\u002FwinappCli --skill pr-lifecycle","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FwinappCli\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-lifecycle\u002FSKILL.md",[],[68,95,129,154,174,188],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":39},"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",[],[75,76,77,78,9,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94],"winui wpf migration","winui","wpf","migration","windows","dispatcher","code","xaml","ui","migrate","system","use","mvvm","app","mapping","port","imaging","errors","namespaces","when",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":111,"publishedAt":39},"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",[101,106],{"categoryNo":102,"categoryName":103,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[112,113,76,83,114,115,116,79,117,118,119,120,121,122,123,124,125,126,127,128,94],"testing","winui ui testing","ui testing","screenshots","sandbox","run","win32","harness","batch","write","feature","end","apps","input","winforms","desktop apps","for",{"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":138,"publishedAt":39},"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",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000030","开发工程师",[139,140,76,141,116,142,79,143,144,145,86,146,147,148,149,150,151,152,153,94],"winui setup","setup","cli","sdk","SET","verify","install","up","repair","requirements","missing","native","toolchain","winapp cli","mode",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":163,"publishedAt":39},"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",[160],{"categoryNo":161,"categoryName":162,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000011","运维与部署",[164,76,165,141,142,166,9,167,79,168,169,170,34,171,172,88,124,126,150,173,152,128,94],"winui packaging","packaging","electron","msix","windows app sdk","ci","certificates","self","project","CI\u002FCD",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":39},"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",[],[181,182,76,183,184,141,142,166,79,37,117,185,34,172,88,186,124,126,150,152,92,187],"workflow","winui dev workflow","dev","dev workflow","fix","diagnosis","new",{"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":204,"publishedAt":39},"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",[194,197,200,201],{"categoryNo":195,"categoryName":196,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":198,"categoryName":199,"taxonomyType":104,"taxonomyTypeDesc":105},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":202,"categoryName":203,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000036","内容创作者",[205,206,76,207,142,208,209,79,168,77,82,83,210,211,212,213,214,88,126,215,128,216],"design","winui design","writing","accessibility","fluent","api","read","layout","pages","bind","controls","fluent design"]