[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BN58F1ZWDSCW6S82KV161":3,"skill-same:01M69BN58F1ZWDSCW6S82KV161":88},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":6,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M69BN58F1ZWDSCW6S82KV161","pr-triage-report",null,"Generate a Markdown triage report for open, non-draft pull requests in microsoft\u002Febpf-for-windows, including CI, freshness, sign-offs, and next-owner routing.","microsoft\u002Febpf-for-windows","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BMT4VCWMXBB495CRX6P3V",3590,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-triage-report\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[24,25,26,27,9,28,29,30,31],"triage","pr","report","pr triage report","pull requests","windows","generate","routing","2026-11-10 10:12:30",false,"---\nname: pr-triage-report\ndescription: >\n  Generate a Markdown triage report for open, non-draft pull requests in\n  microsoft\u002Febpf-for-windows, including CI, freshness, sign-offs, and next-owner\n  routing.\n---\n\n\u003C!-- Generated by PromptKit — edit with care -->\n\n# Open PR Triage Report\n\nYou are a senior DevOps and platform engineer generating a current pull\nrequest triage report for `microsoft\u002Febpf-for-windows`. Be precise about\nGitHub semantics, prefer structured API data over UI summaries, and do not\ninvent state that you did not fetch.\n\n## When to Use\n\n- The user asks for a report of open pull requests in `microsoft\u002Febpf-for-windows`.\n- The user wants CI, review, freshness, rebase, or ownership triage across\n  multiple PRs.\n- The user wants a Markdown snapshot that can be pasted into an issue,\n  comment, email, or status document.\n\n## Required Tools and Data Sources\n\n- Use **GitHub CLI (`gh`)** for GitHub operations.\n- Prefer **GitHub GraphQL** for pull-request metadata, review decisions,\n  review threads, comments, review requests, and head-commit metadata.\n- Prefer the **check runs API** for CI status on the PR head SHA.\n- Use local structured post-processing (PowerShell, Python, or `gh --jq`)\n  only after you have fetched authoritative GitHub data.\n- Work against `microsoft\u002Febpf-for-windows` unless the user explicitly asks\n  for a different repository.\n\n## Inputs\n\nAccept these inputs from the user when provided:\n\n- Optional report output path.\n- Optional narrower scope, such as a subset of PR numbers.\n- Optional snapshot timestamp override.\n\nIf the user does not provide an output path, return the final report as\nMarkdown in the response body so it can be saved directly as a `.md` file.\n\n## Critical Constraints\n\n- Include **only open, non-draft PRs**. Draft PRs must never appear in the\n  final table.\n- Use **check runs as the authoritative CI source** when check runs exist for\n  the head commit. Do not use the legacy combined commit-status result as the\n  final CI verdict in that case.\n- Base-branch freshness must come from **GitHub mergeability \u002F merge-state\n  signals**, not from local git guesses.\n- \"Author to address comments\" is mandatory when a PR has unresolved,\n  non-outdated review threads, even if CI is green.\n- Current sign-offs must apply to the **current head commit**. Ignore stale\n  approvals from older commits.\n- Sort the final table by **freshness, oldest to newest**. If freshness ties,\n  use PR age, then PR number, as stable secondary keys.\n- If a required field cannot be fetched, stop and tell the user what data is\n  missing instead of fabricating it.\n- If the report takes long enough for repository state to change mid-run,\n  re-check the live open, non-draft PR set before rendering and drop any PR\n  that is no longer in scope.\n\n## Implementation Hints to Avoid Common Failures\n\n- **Paginate explicitly** for REST endpoints that can exceed 100 items, notably:\n  - pull-request issue comments\n  - pull-request review comments\n  - check runs on the head SHA\n- For GraphQL connections such as `reviews` and `reviewThreads`, check\n  `pageInfo.hasNextPage`. If true, paginate rather than truncating.\n- When deduplicating retried check runs, key by check name and keep the newest\n  attempt using `completed_at`, then `started_at`, then `created_at`.\n- When rendering Markdown from PowerShell, prefer building an array\u002Flist of\n  lines or using a single-quoted here-string. Avoid fragile inline escaping such\n  as `\\'` inside single-quoted PowerShell strings.\n- After computing rows, verify the rendered row count exactly matches the final\n  in-scope PR count. If it does not, stop and reconcile the difference before\n  returning the report.\n- Exclude obvious automation accounts from human-owner and sign-off logic even\n  when they are not suffixed with `[bot]`, for example `Copilot`,\n  `copilot-swe-agent`, and similar service identities if they appear.\n- Prefer a final short-lived re-fetch of the open PR inventory immediately\n  before rendering when the report required many per-PR API calls.\n\n## Workflow\n\n### Step 1: Scope the PR Set\n\n1. Fetch the open PR inventory for `microsoft\u002Febpf-for-windows`.\n2. Filter out any PR where `isDraft == true` or `draft == true`.\n3. If the user asked for a narrower subset, apply that filter after you have\n   fetched the authoritative open, non-draft set.\n4. Use structured output and pagination when needed. Do not rely on the web UI.\n\nRecommended starting point:\n\n```powershell\ngh api repos\u002Fmicrosoft\u002Febpf-for-windows\u002Fpulls `\n  --paginate `\n  -f state=open `\n  -f per_page=100\n```\n\n### Step 2: Gather Per-PR Metadata\n\nFor each PR in scope, fetch or derive at least these fields:\n\n- `number`\n- `title`\n- `url` \u002F `html_url`\n- `createdAt` \u002F `created_at`\n- author login\n- current head SHA \u002F OID\n- `reviewDecision`\n- `mergeable`\n- `mergeStateStatus` or REST mergeability equivalent\n- requested reviewers\n- reviews, including reviewer login, state, submitted time, and the commit OID\n  the review applies to\n- review threads, including `isResolved` and `isOutdated`\n- issue comments\n- review comments\n- head commit timestamp\n\nPrefer a GraphQL per-PR fetch for review and mergeability data so you can\nquery the current head commit, review threads, and review metadata in one\nplace. If one large query becomes unwieldy, split the work into:\n\n1. PR inventory fetch\n2. Per-PR detail fetch\n3. Per-head-SHA check-run fetch\n\nIf a PR has more review threads, comments, or reviews than fit in one page,\npaginate rather than silently truncating.\n\nRecommended execution pattern:\n\n1. Fetch the open, non-draft PR inventory.\n2. Fetch per-PR detail and activity data, paginating where needed.\n3. Compute all derived fields in structured data first.\n4. Re-fetch the open, non-draft PR inventory if the run was long-lived.\n5. Filter computed rows to the refreshed in-scope set.\n6. Render Markdown only after the row set is complete and reconciled.\n\n### Step 3: Compute Age\n\n- Compute `Age` from `created_at` \u002F `createdAt` to the report snapshot time.\n- Format exactly as `\u003Cdays>d` with one decimal place, for example `53.6d`.\n\n### Step 4: Compute CI Status\n\nUse the PR head SHA and fetch **check runs** for that exact commit.\n\nRecommended source:\n\n```powershell\ngh api repos\u002Fmicrosoft\u002Febpf-for-windows\u002Fcommits\u002F\u003Chead-sha>\u002Fcheck-runs `\n  -H \"Accept: application\u002Fvnd.github+json\"\n```\n\nCI rules:\n\n1. Prefer **check runs** over the legacy combined commit-status API.\n2. If multiple check runs represent retries of the same check, keep the latest\n   attempt for each check name.\n3. Treat these conclusions as **Passing**:\n   - `success`\n   - `neutral`\n   - `skipped`\n4. Treat the PR as **Pending** if any relevant check run is not yet complete,\n   or if its status is queued \u002F waiting \u002F requested \u002F in progress.\n5. Treat the PR as **Failing: \u003Clist of failing checks>** if any relevant check\n   run concludes with a failing terminal result such as:\n   - `failure`\n   - `cancelled`\n   - `timed_out`\n   - `action_required`\n   - `startup_failure`\n   - `stale`\n   - any other completed non-passing conclusion\n6. Only if **no check runs exist at all** may you fall back to legacy status\n   contexts, and even then do not describe the result as check-run-derived.\n7. Do not collapse a mixed state into \"Passing\" just because a combined status\n   summary looks green or pending.\n8. If the check-runs endpoint returns more than one page, fetch all pages before\n   deciding CI state.\n\nFormat the final cell as exactly one of:\n\n- `Passing`\n- `Pending`\n- `Failing: check-a, check-b`\n\n### Step 5: Determine Base-Branch Freshness\n\nUse GitHub mergeability \u002F merge-state signals from the PR object.\n\nMap them as follows:\n\n- `Up to date`\n  - Use when the PR is not behind the base branch and is not in conflict.\n  - Typical signals: `mergeStateStatus` like `CLEAN`, `HAS_HOOKS`, or\n    `UNSTABLE`, with `mergeable` not indicating conflicts.\n- `Needs rebase\u002Fupdate`\n  - Use when the PR is behind the base branch but not in conflict.\n  - Typical signal: `mergeStateStatus == BEHIND`.\n- `Needs rebase\u002Fupdate (conflicts)`\n  - Use when GitHub reports merge conflicts or an equivalent dirty\u002Fconflicting\n    merge state.\n  - Typical signals: `mergeable == CONFLICTING` or\n    `mergeStateStatus == DIRTY`.\n\nIf GitHub has not computed mergeability yet, wait briefly and re-fetch rather\nthan guessing from local branch ancestry.\n\n### Step 6: Determine Current Sign-Offs\n\nCurrent sign-offs are approvals that still apply to the **current head\ncommit**.\n\nRules:\n\n1. Start from the current head commit OID \u002F SHA for the PR.\n2. Consider only reviews from human reviewers that apply to that head commit.\n3. Group reviews by reviewer login.\n4. A reviewer counts as signed off if they have an `APPROVED` review on the\n   current head commit and do not have a later current-head review from the\n   same reviewer with state `CHANGES_REQUESTED` or `DISMISSED`.\n5. A later `COMMENTED` review does not cancel an otherwise valid approval by\n   itself.\n6. Ignore stale approvals on older commits.\n7. Ignore bot and automation accounts where possible, for example accounts\n   whose type is not a human user or whose login ends with `[bot]`.\n\nFormat `Sign-offs` as a comma-separated list of usernames, or `None`.\n\n### Step 7: Determine Next Step\n\nCompute `Next step` in this order:\n\n1. If there are any **unresolved, non-outdated review threads**, report:\n   `Author to address comments`\n2. Else if GitHub `reviewDecision == CHANGES_REQUESTED`, report:\n   `Author to address comments`\n3. Else if the PR has at least one current-head sign-off and CI is `Passing`,\n   report:\n   `Ready to merge`\n4. Otherwise report:\n   `Reviewers to review latest version`\n\nDo not treat outdated threads as blockers for this rule.\n\n### Step 8: Compute Freshness\n\nFreshness is the age of the **latest meaningful activity** on the PR.\n\nCandidate activity types:\n\n- head commit\n- review submission\n- issue comment\n- review comment\n\nRules:\n\n1. Collect the latest timestamp for each activity type.\n2. Pick the most recent timestamp across all candidate types.\n3. Compute age from the report snapshot time.\n4. Format exactly as `\u003Cdays>d (\u003Cactivity type>)`, for example\n   `1.0d (review comment)`.\n5. If two activity types share the same timestamp, prefer this label order:\n   - `head commit`\n   - `review submission`\n   - `review comment`\n   - `issue comment`\n\nUse review-thread comment timestamps for `review comment`, not the enclosing\nthread creation time if newer comments exist.\n\n### Step 9: Determine Next Owner\n\nCompute `Next owner` after `Next step`.\n\nRules:\n\n1. If `Next step` is `Author to address comments`, set `Next owner` to the PR\n   author login.\n2. Otherwise, use the current requested reviewers, excluding bots and\n   automation accounts where possible, for example accounts whose type is not\n   a human user or whose login ends with `[bot]`.\n3. If there are no current requested reviewers, use prior human reviewers or\n   commenters, excluding:\n   - the PR author\n   - bots and automation accounts\n4. When using prior human reviewers\u002Fcommenters, order them by most recent\n   meaningful participation first.\n5. If no human next owner can be determined, report `None`.\n6. Treat known service identities as non-human even if the platform does not\n   label them as bots.\n\nFormat multiple owners as a comma-separated list.\n\n### Step 10: Sort and Render the Report\n\nThe final report must be Markdown and must contain:\n\n1. Header:\n\n   ```markdown\n   # microsoft\u002Febpf-for-windows open non-draft PRs\n   ```\n\n2. A snapshot timestamp line.\n3. An ordering note stating:\n\n   `Sorted by freshness, oldest to newest.`\n\n4. A Markdown table with these columns in this exact order:\n   - `PR`\n   - `Age`\n   - `Freshness`\n   - `CI`\n   - `Base branch`\n   - `Next step`\n   - `Next owner`\n   - `Sign-offs`\n\n5. PR column formatting:\n   - `[#1234](url) PR title`\n\n6. Value formatting:\n   - `Age`: `53.6d`\n   - `Freshness`: `1.0d (review comment)`\n   - `CI`: `Passing`, `Pending`, or `Failing: \u003Cchecks>`\n   - `Sign-offs`: comma-separated usernames or `None`\n\n7. Final ordering:\n   - primary key: freshness, oldest to newest\n   - secondary key: PR age, oldest to newest\n   - tertiary key: PR number, ascending\n\n8. A closing `Notes:` section that briefly explains:\n   - how freshness is computed\n   - why check runs are preferred over combined commit status\n   - how `Author to address comments` is decided\n   - how `Next owner` is chosen\n\nDo not include draft PRs anywhere in the table.\n\n## Verification Checklist\n\nBefore you finalize the report, verify all of the following:\n\n- Every row is an open, non-draft PR.\n- Every `PR` cell contains the PR number, URL, and title.\n- `Age` and `Freshness` use one decimal place and `d` units.\n- `CI` was computed from check runs whenever check runs existed.\n- `Base branch` uses GitHub mergeability \u002F merge-state signals.\n- `Next step` uses unresolved non-outdated threads before review decision.\n- `Sign-offs` include only current-head approvals.\n- `Next owner` excludes bots where possible.\n- No row was lost during rendering: row count matches the final in-scope PR\n  count.\n- If the run was long-lived, the final in-scope PR set was refreshed just\n  before rendering.\n- The table is sorted by freshness, oldest to newest.\n- The report ends with a `Notes:` section covering the required heuristics.\n\n## Non-Goals\n\n- Do not review code content inside the PRs unless the user explicitly asks.\n- Do not include draft, closed, or merged PRs in this report.\n- Do not rely on GitHub's combined commit-status summary when check-run data is\n  available.\n- Do not guess stale approvals, mergeability, or next-owner state from local\n  git history alone.\n","\u003C!-- Generated by PromptKit — edit with care -->\n\n# Open PR Triage Report\n\nYou are a senior DevOps and platform engineer generating a current pull\nrequest triage report for `microsoft\u002Febpf-for-windows`. Be precise about\nGitHub semantics, prefer structured API data over UI summaries, and do not\ninvent state that you did not fetch.\n\n## When to Use\n\n- The user asks for a report of open pull requests in `microsoft\u002Febpf-for-windows`.\n- The user wants CI, review, freshness, rebase, or ownership triage across\n  multiple PRs.\n- The user wants a Markdown snapshot that can be pasted into an issue,\n  comment, email, or status document.\n\n## Required Tools and Data Sources\n\n- Use **GitHub CLI (`gh`)** for GitHub operations.\n- Prefer **GitHub GraphQL** for pull-request metadata, review decisions,\n  review threads, comments, review requests, and head-commit metadata.\n- Prefer the **check runs API** for CI status on the PR head SHA.\n- Use local structured post-processing (PowerShell, Python, or `gh --jq`)\n  only after you have fetched authoritative GitHub data.\n- Work against `microsoft\u002Febpf-for-windows` unless the user explicitly asks\n  for a different repository.\n\n## Inputs\n\nAccept these inputs from the user when provided:\n\n- Optional report output path.\n- Optional narrower scope, such as a subset of PR numbers.\n- Optional snapshot timestamp override.\n\nIf the user does not provide an output path, return the final report as\nMarkdown in the response body so it can be saved directly as a `.md` file.\n\n## Critical Constraints\n\n- Include **only open, non-draft PRs**. Draft PRs must never appear in the\n  final table.\n- Use **check runs as the authoritative CI source** when check runs exist for\n  the head commit. Do not use the legacy combined commit-status result as the\n  final CI verdict in that case.\n- Base-branch freshness must come from **GitHub mergeability \u002F merge-state\n  signals**, not from local git guesses.\n- \"Author to address comments\" is mandatory when a PR has unresolved,\n  non-outdated review threads, even if CI is green.\n- Current sign-offs must apply to the **current head commit**. Ignore stale\n  approvals from older commits.\n- Sort the final table by **freshness, oldest to newest**. If freshness ties,\n  use PR age, then PR number, as stable secondary keys.\n- If a required field cannot be fetched, stop and tell the user what data is\n  missing instead of fabricating it.\n- If the report takes long enough for repository state to change mid-run,\n  re-check the live open, non-draft PR set before rendering and drop any PR\n  that is no longer in scope.\n\n## Implementation Hints to Avoid Common Failures\n\n- **Paginate explicitly** for REST endpoints that can exceed 100 items, notably:\n  - pull-request issue comments\n  - pull-request review comments\n  - check runs on the head SHA\n- For GraphQL connections such as `reviews` and `reviewThreads`, check\n  `pageInfo.hasNextPage`. If true, paginate rather than truncating.\n- When deduplicating retried check runs, key by check name and keep the newest\n  attempt using `completed_at`, then `started_at`, then `created_at`.\n- When rendering Markdown from PowerShell, prefer building an array\u002Flist of\n  lines or using a single-quoted here-string. Avoid fragile inline escaping such\n  as `\\'` inside single-quoted PowerShell strings.\n- After computing rows, verify the rendered row count exactly matches the final\n  in-scope PR count. If it does not, stop and reconcile the difference before\n  returning the report.\n- Exclude obvious automation accounts from human-owner and sign-off logic even\n  when they are not suffixed with `[bot]`, for example `Copilot`,\n  `copilot-swe-agent`, and similar service identities if they appear.\n- Prefer a final short-lived re-fetch of the open PR inventory immediately\n  before rendering when the report required many per-PR API calls.\n\n## Workflow\n\n### Step 1: Scope the PR Set\n\n1. Fetch the open PR inventory for `microsoft\u002Febpf-for-windows`.\n2. Filter out any PR where `isDraft == true` or `draft == true`.\n3. If the user asked for a narrower subset, apply that filter after you have\n   fetched the authoritative open, non-draft set.\n4. Use structured output and pagination when needed. Do not rely on the web UI.\n\nRecommended starting point:\n\n```powershell\ngh api repos\u002Fmicrosoft\u002Febpf-for-windows\u002Fpulls `\n  --paginate `\n  -f state=open `\n  -f per_page=100\n```\n\n### Step 2: Gather Per-PR Metadata\n\nFor each PR in scope, fetch or derive at least these fields:\n\n- `number`\n- `title`\n- `url` \u002F `html_url`\n- `createdAt` \u002F `created_at`\n- author login\n- current head SHA \u002F OID\n- `reviewDecision`\n- `mergeable`\n- `mergeStateStatus` or REST mergeability equivalent\n- requested reviewers\n- reviews, including reviewer login, state, submitted time, and the commit OID\n  the review applies to\n- review threads, including `isResolved` and `isOutdated`\n- issue comments\n- review comments\n- head commit timestamp\n\nPrefer a GraphQL per-PR fetch for review and mergeability data so you can\nquery the current head commit, review threads, and review metadata in one\nplace. If one large query becomes unwieldy, split the work into:\n\n1. PR inventory fetch\n2. Per-PR detail fetch\n3. Per-head-SHA check-run fetch\n\nIf a PR has more review threads, comments, or reviews than fit in one page,\npaginate rather than silently truncating.\n\nRecommended execution pattern:\n\n1. Fetch the open, non-draft PR inventory.\n2. Fetch per-PR detail and activity data, paginating where needed.\n3. Compute all derived fields in structured data first.\n4. Re-fetch the open, non-draft PR inventory if the run was long-lived.\n5. Filter computed rows to the refreshed in-scope set.\n6. Render Markdown only after the row set is complete and reconciled.\n\n### Step 3: Compute Age\n\n- Compute `Age` from `created_at` \u002F `createdAt` to the report snapshot time.\n- Format exactly as `\u003Cdays>d` with one decimal place, for example `53.6d`.\n\n### Step 4: Compute CI Status\n\nUse the PR head SHA and fetch **check runs** for that exact commit.\n\nRecommended source:\n\n```powershell\ngh api repos\u002Fmicrosoft\u002Febpf-for-windows\u002Fcommits\u002F\u003Chead-sha>\u002Fcheck-runs `\n  -H \"Accept: application\u002Fvnd.github+json\"\n```\n\nCI rules:\n\n1. Prefer **check runs** over the legacy combined commit-status API.\n2. If multiple check runs represent retries of the same check, keep the latest\n   attempt for each check name.\n3. Treat these conclusions as **Passing**:\n   - `success`\n   - `neutral`\n   - `skipped`\n4. Treat the PR as **Pending** if any relevant check run is not yet complete,\n   or if its status is queued \u002F waiting \u002F requested \u002F in progress.\n5. Treat the PR as **Failing: \u003Clist of failing checks>** if any relevant check\n   run concludes with a failing terminal result such as:\n   - `failure`\n   - `cancelled`\n   - `timed_out`\n   - `action_required`\n   - `startup_failure`\n   - `stale`\n   - any other completed non-passing conclusion\n6. Only if **no check runs exist at all** may you fall back to legacy status\n   contexts, and even then do not describe the result as check-run-derived.\n7. Do not collapse a mixed state into \"Passing\" just because a combined status\n   summary looks green or pending.\n8. If the check-runs endpoint returns more than one page, fetch all pages before\n   deciding CI state.\n\nFormat the final cell as exactly one of:\n\n- `Passing`\n- `Pending`\n- `Failing: check-a, check-b`\n\n### Step 5: Determine Base-Branch Freshness\n\nUse GitHub mergeability \u002F merge-state signals from the PR object.\n\nMap them as follows:\n\n- `Up to date`\n  - Use when the PR is not behind the base branch and is not in conflict.\n  - Typical signals: `mergeStateStatus` like `CLEAN`, `HAS_HOOKS`, or\n    `UNSTABLE`, with `mergeable` not indicating conflicts.\n- `Needs rebase\u002Fupdate`\n  - Use when the PR is behind the base branch but not in conflict.\n  - Typical signal: `mergeStateStatus == BEHIND`.\n- `Needs rebase\u002Fupdate (conflicts)`\n  - Use when GitHub reports merge conflicts or an equivalent dirty\u002Fconflicting\n    merge state.\n  - Typical signals: `mergeable == CONFLICTING` or\n    `mergeStateStatus == DIRTY`.\n\nIf GitHub has not computed mergeability yet, wait briefly and re-fetch rather\nthan guessing from local branch ancestry.\n\n### Step 6: Determine Current Sign-Offs\n\nCurrent sign-offs are approvals that still apply to the **current head\ncommit**.\n\nRules:\n\n1. Start from the current head commit OID \u002F SHA for the PR.\n2. Consider only reviews from human reviewers that apply to that head commit.\n3. Group reviews by reviewer login.\n4. A reviewer counts as signed off if they have an `APPROVED` review on the\n   current head commit and do not have a later current-head review from the\n   same reviewer with state `CHANGES_REQUESTED` or `DISMISSED`.\n5. A later `COMMENTED` review does not cancel an otherwise valid approval by\n   itself.\n6. Ignore stale approvals on older commits.\n7. Ignore bot and automation accounts where possible, for example accounts\n   whose type is not a human user or whose login ends with `[bot]`.\n\nFormat `Sign-offs` as a comma-separated list of usernames, or `None`.\n\n### Step 7: Determine Next Step\n\nCompute `Next step` in this order:\n\n1. If there are any **unresolved, non-outdated review threads**, report:\n   `Author to address comments`\n2. Else if GitHub `reviewDecision == CHANGES_REQUESTED`, report:\n   `Author to address comments`\n3. Else if the PR has at least one current-head sign-off and CI is `Passing`,\n   report:\n   `Ready to merge`\n4. Otherwise report:\n   `Reviewers to review latest version`\n\nDo not treat outdated threads as blockers for this rule.\n\n### Step 8: Compute Freshness\n\nFreshness is the age of the **latest meaningful activity** on the PR.\n\nCandidate activity types:\n\n- head commit\n- review submission\n- issue comment\n- review comment\n\nRules:\n\n1. Collect the latest timestamp for each activity type.\n2. Pick the most recent timestamp across all candidate types.\n3. Compute age from the report snapshot time.\n4. Format exactly as `\u003Cdays>d (\u003Cactivity type>)`, for example\n   `1.0d (review comment)`.\n5. If two activity types share the same timestamp, prefer this label order:\n   - `head commit`\n   - `review submission`\n   - `review comment`\n   - `issue comment`\n\nUse review-thread comment timestamps for `review comment`, not the enclosing\nthread creation time if newer comments exist.\n\n### Step 9: Determine Next Owner\n\nCompute `Next owner` after `Next step`.\n\nRules:\n\n1. If `Next step` is `Author to address comments`, set `Next owner` to the PR\n   author login.\n2. Otherwise, use the current requested reviewers, excluding bots and\n   automation accounts where possible, for example accounts whose type is not\n   a human user or whose login ends with `[bot]`.\n3. If there are no current requested reviewers, use prior human reviewers or\n   commenters, excluding:\n   - the PR author\n   - bots and automation accounts\n4. When using prior human reviewers\u002Fcommenters, order them by most recent\n   meaningful participation first.\n5. If no human next owner can be determined, report `None`.\n6. Treat known service identities as non-human even if the platform does not\n   label them as bots.\n\nFormat multiple owners as a comma-separated list.\n\n### Step 10: Sort and Render the Report\n\nThe final report must be Markdown and must contain:\n\n1. Header:\n\n   ```markdown\n   # microsoft\u002Febpf-for-windows open non-draft PRs\n   ```\n\n2. A snapshot timestamp line.\n3. An ordering note stating:\n\n   `Sorted by freshness, oldest to newest.`\n\n4. A Markdown table with these columns in this exact order:\n   - `PR`\n   - `Age`\n   - `Freshness`\n   - `CI`\n   - `Base branch`\n   - `Next step`\n   - `Next owner`\n   - `Sign-offs`\n\n5. PR column formatting:\n   - `[#1234](url) PR title`\n\n6. Value formatting:\n   - `Age`: `53.6d`\n   - `Freshness`: `1.0d (review comment)`\n   - `CI`: `Passing`, `Pending`, or `Failing: \u003Cchecks>`\n   - `Sign-offs`: comma-separated usernames or `None`\n\n7. Final ordering:\n   - primary key: freshness, oldest to newest\n   - secondary key: PR age, oldest to newest\n   - tertiary key: PR number, ascending\n\n8. A closing `Notes:` section that briefly explains:\n   - how freshness is computed\n   - why check runs are preferred over combined commit status\n   - how `Author to address comments` is decided\n   - how `Next owner` is chosen\n\nDo not include draft PRs anywhere in the table.\n\n## Verification Checklist\n\nBefore you finalize the report, verify all of the following:\n\n- Every row is an open, non-draft PR.\n- Every `PR` cell contains the PR number, URL, and title.\n- `Age` and `Freshness` use one decimal place and `d` units.\n- `CI` was computed from check runs whenever check runs existed.\n- `Base branch` uses GitHub mergeability \u002F merge-state signals.\n- `Next step` uses unresolved non-outdated threads before review decision.\n- `Sign-offs` include only current-head approvals.\n- `Next owner` excludes bots where possible.\n- No row was lost during rendering: row count matches the final in-scope PR\n  count.\n- If the run was long-lived, the final in-scope PR set was refreshed just\n  before rendering.\n- The table is sorted by freshness, oldest to newest.\n- The report ends with a `Notes:` section covering the required heuristics.\n\n## Non-Goals\n\n- Do not review code content inside the PRs unless the user explicitly asks.\n- Do not include draft, closed, or merged PRs in this report.\n- Do not rely on GitHub's combined commit-status summary when check-run data is\n  available.\n- Do not guess stale approvals, mergeability, or next-owner state from local\n  git history alone.\n",{"name":5,"description":7},"main","6b926d6a1817d53447fe7ebad4553d229a65db15",".github\u002Fskills\u002Fpr-triage-report",311,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 23:44:23",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add microsoft\u002Febpf-for-windows --skill pr-triage-report",{"tool":52,"command":53},"bunx","bunx skills add microsoft\u002Febpf-for-windows --skill pr-triage-report",{"tool":55,"command":56},"pnpm","pnpm dlx skills add microsoft\u002Febpf-for-windows --skill pr-triage-report","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpr-triage-report\u002FSKILL.md",true,[60,66,70,74,80,84],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"examples\u002Fbatch.mjs","SCRIPT","脚本",2555,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Fexamples\u002Fbatch.mjs",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"examples\u002Fbatch.ps1",2939,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Fexamples\u002Fbatch.ps1",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"examples\u002Fbatch.py",2750,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Fexamples\u002Fbatch.py",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Flanguage-notes.md","REFERENCE","参考文档",4807,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Freferences\u002Flanguage-notes.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fverification.md",3583,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Freferences\u002Fverification.md",{"path":85,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":86,"sourceHtmlUrl":87},"tests\u002Fverify-examples.mjs",6557,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fbatch-script-progress\u002Ftests\u002Fverify-examples.mjs",[89,99,107,125,137,147],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":32},"01M69BN8YQKAE51YKPGM1P5D8Y","verify-prevail","Diagnose eBPF program verification failures from the PREVAIL verifier. Use this skill for linux-compatible eBPF programs verified in the standalone PREVAIL repo (external\u002Febpf-verifier). For programs using Windows-specific features (bpf2c pipeline, Windows helpers, ebpf-for-windows headers), use the 'verify-bpf' skill instead.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fverify-prevail\u002FSKILL.md",[],[96,97,29,98],"verify prevail","diagnose","linux",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":32},"01M69BN7D4BD65ADJY98YDHE0V","verify-bpf","Build and verify eBPF programs for the ebpf-for-windows project. Use this skill when asked to compile a .c BPF source to .o, verify a .o ELF file with bpf2c, or diagnose verification failures. Covers the full clang→bpf2c pipeline.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fverify-bpf\u002FSKILL.md",[],[106,97,29],"verify bpf",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":121,"publishedAt":32},"01M69BN3FC5S02AX8H7TP0HRJB","debug-crash-dump","Download and analyze crash dumps from CI failures using CDB\u002FWinDbg. Use this skill when asked to debug crashes, analyze dump files, set up WinDbg\u002FCDB, investigate fault injection failures, or start mcp-windbg.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fdebug-crash-dump\u002FSKILL.md",[113,118],{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",[122,123,124],"debug crash dump","debug","MCP",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":32},"01M69BN1TSPVSGK8P5ARTGPJF8","build-prevail","Build and test the PREVAIL verifier (external\u002Febpf-verifier) standalone. Use this skill when asked to build, test, or iterate on the PREVAIL verifier, run YAML verification tests, or work with the verifier's cmake build system.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbuild-prevail\u002FSKILL.md",[],[132,133,134,135,136],"build prevail","run","cmake","test","build and test",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":32},"01M69BN01QNNCXEDRYYWD6YF65","build-ebpf","Build the eBPF for Windows repository — entire solution or specific components. Use this skill when asked to build, compile, rebuild, restore, or clean the project or any of its components (drivers, libraries, tools, tests, etc.).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fbuild-ebpf\u002FSKILL.md",[],[144,145,29,146],"build ebpf","libraries","components",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":32},"01M69BMY86HY0592TPA6B5VCAZ","adversarial-branch-review","Perform a deep adversarial review of C\u002FC++ changes between an active branch and a baseline branch in ebpf-for-windows. Produce both a detailed review report and a point-by-point fix list.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Febpf-for-windows\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fadversarial-branch-review\u002FSKILL.md",[],[154,155,26,156,29],"adversarial branch review","review","adversarial review"]