[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PJ5E3PCBDS319FFMHPFACN":3,"skill-same:01M6PJ5E3PCBDS319FFMHPFACN":80},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6PJ5E3PCBDS319FFMHPFACN","review-pr-local",null,"The authority on pulling a pull request — Azure DevOps or GitHub — into an isolated local worktree so a human can review it in their editor, and on posting human-controlled review comments back to the PR (ADO via the ado PR-thread MCP tools or the Azure DevOps REST API, GitHub via the gh CLI). Auto-detects the platform and all identifiers from the PR URL; not tied to any specific repository. The AI assists an interactive human review and only ever posts comments the human explicitly requests. If you find yourself checking out a PR branch over the user's own working tree, or posting AI-authored review prose the human did not ask for, invoke this skill instead.","microsoft\u002FFluidFramework","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AG0BQKNGBJQ5YNG09HXXW",4947,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview-pr-local\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"review","review pr","review pr local","pr","local","invoke","MCP","authority","posts","you","URL","back","only","auto","ask","branch","api","worktree","azure devops","cli","2026-11-10 10:12:30",false,"---\nname: review-pr-local\ndescription: The authority on pulling a pull request — Azure DevOps or GitHub — into an isolated local worktree so a human can review it in their editor, and on posting human-controlled review comments back to the PR (ADO via the ado PR-thread MCP tools or the Azure DevOps REST API, GitHub via the gh CLI). Auto-detects the platform and all identifiers from the PR URL; not tied to any specific repository. The AI assists an interactive human review and only ever posts comments the human explicitly requests. If you find yourself checking out a PR branch over the user's own working tree, or posting AI-authored review prose the human did not ask for, invoke this skill instead.\nlicense: MIT\nargument-hint: \"[PR-url]\"\n---\n\n# Review a PR Locally (ADO + GitHub)\n\nCheck out a pull request into an **isolated git worktree** — never disturbing the user's current checkout — surface its changes in the editor, run an interactive review where the human drives, and post only the comments the human asks for. All identifiers are derived from the PR URL, so the skill works against any ADO or GitHub repository.\n\n## Tool and workspace boundaries\n\n- Use Copilot's file-reading and search tools for inspection.\n- Restrict shell commands to `git`, `az`, and `gh`, plus the minimum JSON serialization and targeted temporary-file cleanup required by the documented ADO REST fallback.\n- Use `ask_user` whenever the workflow requires information or approval from the human.\n- Do not edit source files in either the user's checkout or the review worktree.\n- Do not commit, push, merge, approve, or otherwise change the reviewed branch.\n- Post a review comment only when the human explicitly requests that specific comment, following the approval rules below.\n\n## Review Philosophy — high-signal, human-owned\n\nThis is the core of the skill. Violating it defeats the purpose.\n\n- **The human drives the review.** The AI surfaces the parts worth attention and answers the human's questions. It never decides on its own to flood the PR with comments.\n- **Comments are posted only on explicit human request**, in one of two ways:\n  1. **Human-dictated:** the human gives exact location + text (e.g. `post comment on line 53 of src\u002Ffoo.ts - this returns before the lock is released`). Post it verbatim.\n  2. **AI-drafted on request:** the human asks the AI to write a comment for a specific spot (e.g. `add a comment on the null check in bar.ts`). Draft it terse and high-signal, show it, and post only after the human approves.\n- **When surfacing \"important parts,\" comment-worthy means:** correctness bugs, logic errors, security issues, breaking API changes, missing edge cases, data loss\u002Fcorruption, race conditions, broken error handling. Ignore style, formatting, and naming.\n- **Never post** praise, summaries, restatements of what the code does, or style nits — in either mode.\n- **Every posted comment** cites a concrete `file:line` and is 1–3 sentences.\n\n## Step 1 — Parse the PR URL\n\nDetect the platform and extract every identifier from the URL — nothing is hardcoded.\n\n| Platform | URL shape | Extract |\n|----------|-----------|---------|\n| Azure DevOps | `https:\u002F\u002F\u003Corg>.visualstudio.com\u002F\u003Cproject>\u002F_git\u002F\u003Crepo>\u002Fpullrequest\u002F\u003Cid>` or `https:\u002F\u002Fdev.azure.com\u002F\u003Corg>\u002F\u003Cproject>\u002F_git\u002F\u003Crepo>\u002Fpullrequest\u002F\u003Cid>` | org, project, repo, id |\n| GitHub | `https:\u002F\u002Fgithub.com\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpull\u002F\u003Cnumber>` | owner, repo, number |\n\nIf given a bare number instead of a URL, use `ask_user` to get the full URL (or the platform + identifiers).\n\n## Step 2 — Prerequisites (self-contained)\n\n| Platform | Ensure tooling | Auth check → recovery |\n|----------|----------------|-----------------------|\n| Azure DevOps | `az extension show --name azure-devops` — if absent, `az extension add --name azure-devops` | `az account show`; on failure prompt the user to run `az login`, then stop |\n| GitHub | `gh --version` | `gh auth status`; on failure prompt the user to run `gh auth login`, then stop |\n\nFor ADO, pass the org explicitly on every command: `--organization https:\u002F\u002F\u003Corg>.visualstudio.com`. If any later `az` call fails with an auth error, prompt the user to re-run `az login`.\n\n## Step 3 — Resolve PR metadata\n\n| Platform | Command | Fields |\n|----------|---------|--------|\n| Azure DevOps | `az repos pr show --id \u003Cid> --organization https:\u002F\u002F\u003Corg>.visualstudio.com --output json` | `sourceRefName`, `targetRefName`, `lastMergeSourceCommit.commitId` (head), `lastMergeTargetCommit.commitId` (base) |\n| GitHub | `gh pr view \u003Cnumber> --repo \u003Cowner>\u002F\u003Crepo> --json headRefName,baseRefName,headRefOid,baseRefOid` | `headRefName`, `baseRefName`, `headRefOid` (head), `baseRefOid` (base) |\n\n## Step 4 — Fetch the PR into an isolated worktree\n\nNever run `git checkout` \u002F `gh pr checkout` in the user's working directory. Always use a separate worktree.\n\n1. Reuse an existing worktree if present:\n   - Repo root: `git rev-parse --show-toplevel`.\n   - Worktree path: sibling of the repo root named `\u003Crepo-name>-pr-\u003Cid-or-number>`.\n   - If it already appears in `git worktree list`, skip to Step 5.\n2. Fetch the head and base commits:\n\n   | Platform | Fetch head | Fetch base |\n   |----------|------------|------------|\n   | Azure DevOps | `git fetch origin \u003Csource-branch>` | `git fetch origin \u003Chead-commit> \u003Cbase-commit>` |\n   | GitHub | `git fetch origin pull\u002F\u003Cnumber>\u002Fhead` (works for forks) | `git fetch origin \u003Cbase-branch>` |\n\n3. Create a **detached** worktree at the head commit (detached avoids \"branch already checked out\" errors and leaves no stray local branch):\n\n   ```\n   git worktree add --detach \u003Cworktree-path> \u003Chead-commit>\n   ```\n\n   This writes the full tree and can take minutes on a large monorepo — use a long timeout and let it finish.\n\n## Step 5 — Surface the PR changes in the editor\n\nThe editor's Source Control panel shows only *uncommitted* changes, so a committed PR branch looks empty. Soft-reset the detached worktree to the PR's merge-base so the PR's changes become staged changes with per-file diffs.\n\n1. Merge-base (isolates the PR's own changes): `git -C \u003Cworktree-path> merge-base \u003Chead-commit> \u003Cbase-commit>`\n2. Verify the real file set first: `git -C \u003Cworktree-path> diff --stat \u003Cmerge-base> \u003Chead-commit>`\n3. Surface as staged: `git -C \u003Cworktree-path> reset --soft \u003Cmerge-base>`\n4. Offer to open it: `code \u003Cworktree-path>` — changed files appear under **Staged Changes**. Tell the user not to run `git pull` there (it re-applies the commits and hides the diff); an already-open editor needs a Source Control refresh.\n\n## Step 6 — Interactive review\n\n1. Read the three-dot diff (`\u003Cmerge-base>..\u003Chead-commit>`) and the modified files for context.\n2. Present a short list of the **important parts** (per the Philosophy bar), each as `file:line` + a one-line reason. Default to few.\n3. Answer the human's follow-up questions about any file, hunk, or symbol — read more of the tree as needed. Stay in this loop until the human is ready to comment or finish.\n\n## Step 7 — Post comments the human requests\n\nParse each request into `file`, `line`, and `body` (draft the body only if the human asked the AI to write it, then get approval). Post one comment per request. Read existing threads first to avoid duplicates.\n\nAnchor identifiers come from Step 1 (org\u002Fproject\u002Frepo\u002Fid) and Step 3 (`\u003Chead-commit>`). File paths are repo-relative. In the examples below, substitute the values parsed in Step 1 for every `\u003C...>` placeholder.\n\n### Azure DevOps — inline (anchored to a line)\n\nPreferred: the `ado\u002Frepo_create_pull_request_thread` MCP tool with a `threadContext`:\n\n```\norganization:  \u003Corg>\nproject:       \u003Cproject>\nrepositoryId:  \u003Crepo>\npullRequestId: \u003Cid>                         # integer\ncontent:       \"This returns before the lock is released.\"\nthreadContext:\n  filePath:        \"\u002F\u003Crepo-relative-path>\"  # leading slash\n  rightFileStart:  { line: \u003Cn>, offset: 1 }\n  rightFileEnd:    { line: \u003Cn>, offset: 5 }\n```\n\nREST fallback (when the `ado` MCP server is not configured) — uses the `az login` token:\n\n```\naz rest --method post \\\n  --resource 499b84ac-1321-427f-aa17-267ca6975798 \\\n  --uri \"https:\u002F\u002Fdev.azure.com\u002F\u003Corg>\u002F\u003Cproject>\u002F_apis\u002Fgit\u002Frepositories\u002F\u003Crepo>\u002FpullRequests\u002F\u003Cid>\u002Fthreads?api-version=7.1\" \\\n  --headers \"Content-Type=application\u002Fjson\" \\\n  --body @thread-body.json\n```\n\nwhere `thread-body.json` is `{ \"comments\": [{ \"parentCommentId\": 0, \"content\": \"...\", \"commentType\": 1 }], \"status\": \"active\", \"threadContext\": { \"filePath\": \"\u002F\u003Crepo-relative-path>\", \"rightFileStart\": { \"line\": \u003Cn>, \"offset\": 1 }, \"rightFileEnd\": { \"line\": \u003Cn>, \"offset\": 5 } } }`. Generate the body with a JSON serializer, not string interpolation. Delete the temp file afterward.\n\n### Azure DevOps — general (PR-level)\n\nSame MCP tool or REST call, **omit** `threadContext` (and the body's `threadContext`).\n\n### GitHub — inline (anchored to a line)\n\n```\ngh api --method POST \u002Frepos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpulls\u002F\u003Cnumber>\u002Fcomments \\\n  -f body=\"This returns before the lock is released.\" \\\n  -f commit_id=\u003Chead-commit> \\\n  -f path=\u003Crepo-relative-path> \\\n  -F line=\u003Cn> \\\n  -f side=RIGHT\n```\n\nTo post several inline comments as one review, batch them via `gh api \u002Frepos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpulls\u002F\u003Cnumber>\u002Freviews` (event `COMMENT`).\n\n### GitHub — general (PR-level)\n\n```\ngh pr comment \u003Cnumber> --repo \u003Cowner>\u002F\u003Crepo> \\\n  --body \"Validation approach looks solid overall.\"\n```\n\nRules for all paths: call ADO MCP tools server-qualified (`ado\u002Frepo_*`) — never `ado-repo_*` aliases; `pullRequestId` is an integer; prefer inline over general when the human gives a line. Confirm each post back to the human with the PR link.\n\n## Step 8 — Cleanup\n\nWhen finished, remove the worktree (never affects the user's own branch):\n\n```\ngit worktree remove --force \u003Cworktree-path>\n```\n\nIf the directory is locked (an editor still has it open), close that editor window, then re-run the remove and `git worktree prune`.\n\n## Error handling\n\n- **Stale `origin`:** if the three-dot diff looks far larger than the PR, the local base ref is stale — re-fetch the base commit\u002Fbranch and recompute the merge-base.\n- **Fork PR (GitHub):** always fetch via `pull\u002F\u003Cnumber>\u002Fhead`; don't assume the head branch exists on `origin`.\n- **Slow checkout:** the full-tree checkout on a large monorepo can take minutes — use a long timeout rather than interrupting.\n","# Review a PR Locally (ADO + GitHub)\n\nCheck out a pull request into an **isolated git worktree** — never disturbing the user's current checkout — surface its changes in the editor, run an interactive review where the human drives, and post only the comments the human asks for. All identifiers are derived from the PR URL, so the skill works against any ADO or GitHub repository.\n\n## Tool and workspace boundaries\n\n- Use Copilot's file-reading and search tools for inspection.\n- Restrict shell commands to `git`, `az`, and `gh`, plus the minimum JSON serialization and targeted temporary-file cleanup required by the documented ADO REST fallback.\n- Use `ask_user` whenever the workflow requires information or approval from the human.\n- Do not edit source files in either the user's checkout or the review worktree.\n- Do not commit, push, merge, approve, or otherwise change the reviewed branch.\n- Post a review comment only when the human explicitly requests that specific comment, following the approval rules below.\n\n## Review Philosophy — high-signal, human-owned\n\nThis is the core of the skill. Violating it defeats the purpose.\n\n- **The human drives the review.** The AI surfaces the parts worth attention and answers the human's questions. It never decides on its own to flood the PR with comments.\n- **Comments are posted only on explicit human request**, in one of two ways:\n  1. **Human-dictated:** the human gives exact location + text (e.g. `post comment on line 53 of src\u002Ffoo.ts - this returns before the lock is released`). Post it verbatim.\n  2. **AI-drafted on request:** the human asks the AI to write a comment for a specific spot (e.g. `add a comment on the null check in bar.ts`). Draft it terse and high-signal, show it, and post only after the human approves.\n- **When surfacing \"important parts,\" comment-worthy means:** correctness bugs, logic errors, security issues, breaking API changes, missing edge cases, data loss\u002Fcorruption, race conditions, broken error handling. Ignore style, formatting, and naming.\n- **Never post** praise, summaries, restatements of what the code does, or style nits — in either mode.\n- **Every posted comment** cites a concrete `file:line` and is 1–3 sentences.\n\n## Step 1 — Parse the PR URL\n\nDetect the platform and extract every identifier from the URL — nothing is hardcoded.\n\n| Platform | URL shape | Extract |\n|----------|-----------|---------|\n| Azure DevOps | `https:\u002F\u002F\u003Corg>.visualstudio.com\u002F\u003Cproject>\u002F_git\u002F\u003Crepo>\u002Fpullrequest\u002F\u003Cid>` or `https:\u002F\u002Fdev.azure.com\u002F\u003Corg>\u002F\u003Cproject>\u002F_git\u002F\u003Crepo>\u002Fpullrequest\u002F\u003Cid>` | org, project, repo, id |\n| GitHub | `https:\u002F\u002Fgithub.com\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpull\u002F\u003Cnumber>` | owner, repo, number |\n\nIf given a bare number instead of a URL, use `ask_user` to get the full URL (or the platform + identifiers).\n\n## Step 2 — Prerequisites (self-contained)\n\n| Platform | Ensure tooling | Auth check → recovery |\n|----------|----------------|-----------------------|\n| Azure DevOps | `az extension show --name azure-devops` — if absent, `az extension add --name azure-devops` | `az account show`; on failure prompt the user to run `az login`, then stop |\n| GitHub | `gh --version` | `gh auth status`; on failure prompt the user to run `gh auth login`, then stop |\n\nFor ADO, pass the org explicitly on every command: `--organization https:\u002F\u002F\u003Corg>.visualstudio.com`. If any later `az` call fails with an auth error, prompt the user to re-run `az login`.\n\n## Step 3 — Resolve PR metadata\n\n| Platform | Command | Fields |\n|----------|---------|--------|\n| Azure DevOps | `az repos pr show --id \u003Cid> --organization https:\u002F\u002F\u003Corg>.visualstudio.com --output json` | `sourceRefName`, `targetRefName`, `lastMergeSourceCommit.commitId` (head), `lastMergeTargetCommit.commitId` (base) |\n| GitHub | `gh pr view \u003Cnumber> --repo \u003Cowner>\u002F\u003Crepo> --json headRefName,baseRefName,headRefOid,baseRefOid` | `headRefName`, `baseRefName`, `headRefOid` (head), `baseRefOid` (base) |\n\n## Step 4 — Fetch the PR into an isolated worktree\n\nNever run `git checkout` \u002F `gh pr checkout` in the user's working directory. Always use a separate worktree.\n\n1. Reuse an existing worktree if present:\n   - Repo root: `git rev-parse --show-toplevel`.\n   - Worktree path: sibling of the repo root named `\u003Crepo-name>-pr-\u003Cid-or-number>`.\n   - If it already appears in `git worktree list`, skip to Step 5.\n2. Fetch the head and base commits:\n\n   | Platform | Fetch head | Fetch base |\n   |----------|------------|------------|\n   | Azure DevOps | `git fetch origin \u003Csource-branch>` | `git fetch origin \u003Chead-commit> \u003Cbase-commit>` |\n   | GitHub | `git fetch origin pull\u002F\u003Cnumber>\u002Fhead` (works for forks) | `git fetch origin \u003Cbase-branch>` |\n\n3. Create a **detached** worktree at the head commit (detached avoids \"branch already checked out\" errors and leaves no stray local branch):\n\n   ```\n   git worktree add --detach \u003Cworktree-path> \u003Chead-commit>\n   ```\n\n   This writes the full tree and can take minutes on a large monorepo — use a long timeout and let it finish.\n\n## Step 5 — Surface the PR changes in the editor\n\nThe editor's Source Control panel shows only *uncommitted* changes, so a committed PR branch looks empty. Soft-reset the detached worktree to the PR's merge-base so the PR's changes become staged changes with per-file diffs.\n\n1. Merge-base (isolates the PR's own changes): `git -C \u003Cworktree-path> merge-base \u003Chead-commit> \u003Cbase-commit>`\n2. Verify the real file set first: `git -C \u003Cworktree-path> diff --stat \u003Cmerge-base> \u003Chead-commit>`\n3. Surface as staged: `git -C \u003Cworktree-path> reset --soft \u003Cmerge-base>`\n4. Offer to open it: `code \u003Cworktree-path>` — changed files appear under **Staged Changes**. Tell the user not to run `git pull` there (it re-applies the commits and hides the diff); an already-open editor needs a Source Control refresh.\n\n## Step 6 — Interactive review\n\n1. Read the three-dot diff (`\u003Cmerge-base>..\u003Chead-commit>`) and the modified files for context.\n2. Present a short list of the **important parts** (per the Philosophy bar), each as `file:line` + a one-line reason. Default to few.\n3. Answer the human's follow-up questions about any file, hunk, or symbol — read more of the tree as needed. Stay in this loop until the human is ready to comment or finish.\n\n## Step 7 — Post comments the human requests\n\nParse each request into `file`, `line`, and `body` (draft the body only if the human asked the AI to write it, then get approval). Post one comment per request. Read existing threads first to avoid duplicates.\n\nAnchor identifiers come from Step 1 (org\u002Fproject\u002Frepo\u002Fid) and Step 3 (`\u003Chead-commit>`). File paths are repo-relative. In the examples below, substitute the values parsed in Step 1 for every `\u003C...>` placeholder.\n\n### Azure DevOps — inline (anchored to a line)\n\nPreferred: the `ado\u002Frepo_create_pull_request_thread` MCP tool with a `threadContext`:\n\n```\norganization:  \u003Corg>\nproject:       \u003Cproject>\nrepositoryId:  \u003Crepo>\npullRequestId: \u003Cid>                         # integer\ncontent:       \"This returns before the lock is released.\"\nthreadContext:\n  filePath:        \"\u002F\u003Crepo-relative-path>\"  # leading slash\n  rightFileStart:  { line: \u003Cn>, offset: 1 }\n  rightFileEnd:    { line: \u003Cn>, offset: 5 }\n```\n\nREST fallback (when the `ado` MCP server is not configured) — uses the `az login` token:\n\n```\naz rest --method post \\\n  --resource 499b84ac-1321-427f-aa17-267ca6975798 \\\n  --uri \"https:\u002F\u002Fdev.azure.com\u002F\u003Corg>\u002F\u003Cproject>\u002F_apis\u002Fgit\u002Frepositories\u002F\u003Crepo>\u002FpullRequests\u002F\u003Cid>\u002Fthreads?api-version=7.1\" \\\n  --headers \"Content-Type=application\u002Fjson\" \\\n  --body @thread-body.json\n```\n\nwhere `thread-body.json` is `{ \"comments\": [{ \"parentCommentId\": 0, \"content\": \"...\", \"commentType\": 1 }], \"status\": \"active\", \"threadContext\": { \"filePath\": \"\u002F\u003Crepo-relative-path>\", \"rightFileStart\": { \"line\": \u003Cn>, \"offset\": 1 }, \"rightFileEnd\": { \"line\": \u003Cn>, \"offset\": 5 } } }`. Generate the body with a JSON serializer, not string interpolation. Delete the temp file afterward.\n\n### Azure DevOps — general (PR-level)\n\nSame MCP tool or REST call, **omit** `threadContext` (and the body's `threadContext`).\n\n### GitHub — inline (anchored to a line)\n\n```\ngh api --method POST \u002Frepos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpulls\u002F\u003Cnumber>\u002Fcomments \\\n  -f body=\"This returns before the lock is released.\" \\\n  -f commit_id=\u003Chead-commit> \\\n  -f path=\u003Crepo-relative-path> \\\n  -F line=\u003Cn> \\\n  -f side=RIGHT\n```\n\nTo post several inline comments as one review, batch them via `gh api \u002Frepos\u002F\u003Cowner>\u002F\u003Crepo>\u002Fpulls\u002F\u003Cnumber>\u002Freviews` (event `COMMENT`).\n\n### GitHub — general (PR-level)\n\n```\ngh pr comment \u003Cnumber> --repo \u003Cowner>\u002F\u003Crepo> \\\n  --body \"Validation approach looks solid overall.\"\n```\n\nRules for all paths: call ADO MCP tools server-qualified (`ado\u002Frepo_*`) — never `ado-repo_*` aliases; `pullRequestId` is an integer; prefer inline over general when the human gives a line. Confirm each post back to the human with the PR link.\n\n## Step 8 — Cleanup\n\nWhen finished, remove the worktree (never affects the user's own branch):\n\n```\ngit worktree remove --force \u003Cworktree-path>\n```\n\nIf the directory is locked (an editor still has it open), close that editor window, then re-run the remove and `git worktree prune`.\n\n## Error handling\n\n- **Stale `origin`:** if the three-dot diff looks far larger than the PR, the local base ref is stale — re-fetch the base commit\u002Fbranch and recompute the merge-base.\n- **Fork PR (GitHub):** always fetch via `pull\u002F\u003Cnumber>\u002Fhead`; don't assume the head branch exists on `origin`.\n- **Slow checkout:** the full-tree checkout on a large monorepo can take minutes — use a long timeout rather than interrupting.\n",{"name":5,"license":15,"description":7,"argument-hint":49},"[PR-url]","main","8809386f7af487f40be7dcbea5d0e4afc37efd0a",".github\u002Fskills\u002Freview-pr-local",590,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework","https:\u002F\u002Ffluidframework.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 03:12:28",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add microsoft\u002FFluidFramework --skill review-pr-local",{"tool":66,"command":67},"bunx","bunx skills add microsoft\u002FFluidFramework --skill review-pr-local",{"tool":69,"command":70},"pnpm","pnpm dlx skills add microsoft\u002FFluidFramework --skill review-pr-local","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview-pr-local\u002FSKILL.md",true,[74],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"evals\u002Fevals.json","REFERENCE","参考文档",4087,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview-pr-local\u002Fevals\u002Fevals.json",[81,102,135,153,176,200],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":44},"01M6PJ5SAHYFZFWDG5Y4RW56EP","trigger-pipelines-for-copilot-pr","Trigger ADO pipelines for a Copilot-created PR by posting \u002Fazp run comments. Use when the user asks to trigger CI pipelines for a specific PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftrigger-pipelines-for-copilot-pr\u002FSKILL.md",[],[27,88,89,90,91,92,93,94,95,96,97,98,34,99,100,101],"trigger pipelines for copilot pr","for","trigger","copilot","pipelines","ado","posting","run","ci","use","number","comments","user","when",{"skillNo":103,"name":24,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":118,"publishedAt":44},"01M6PJ5M4ZG7E78C4GM4041HEP","Review changes relative to a prior state, such as a diff, pull request, branch, commit, or working-tree changes. Use for change-focused code review and regression analysis. Do not use to assess an existing file, API, design, implementation, or other artifact without a comparison; if the request is ambiguous, ask whether the user wants a change review and what prior state to compare against.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview\u002FSKILL.md",[107,110,113],{"categoryNo":108,"categoryName":109,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":111,"categoryName":112,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,39,119,120,121,38,122,123,124,40,125,126,127,128,129,130,131,132,89,133,134],"regression","code review","design","analysis","code","commit","change","artifact","request","pull","tree","as","do","diff","assess","ambiguous",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":44},"01M6PJ5AVZAS0AEBPCYJZ9ZMMD","policy-check","This skill should be used when the user asks to \"run policy check\", \"check policy\", \"policy-check\", or needs to validate package compliance. Provides guidance on running policy checks for specific packages or the entire repository.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpolicy-check\u002FSKILL.md",[],[142,143,144,145,146,89,95,147,148,149,150,100,151,101,152],"policy check","policy","check","packages","compliance","repository","guidance","validate","package","running","entire",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":44},"01M6PJ54H068MZF2WD2JDKCVDC","pipeline-test-triage","Triage test failures in an Azure DevOps pipeline run for Fluid Framework. Use when the user shares an ADO build\u002Fpipeline URL or build ID and wants failures analyzed, when they ask \"why did this pipeline fail\", \"summarize the test failures\", \"is this test flaky or a real bug\", \"compare these runs\", or wants bugs filed for genuine failures. Covers the Real Service End to End Tests pipeline as the worked example but applies to any FF test pipeline.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpipeline-test-triage\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[163,164,165,166,167,168,169,170,42,34,38,95,171,172,173,174,93,130,175,89,101],"pipeline","test triage","pipeline test triage","pipeline test","test","triage","end","test pipeline","why","bug","but","framework","bugs",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":44},"01M6PJ4ZJASDV2CGQTG1JWKBFE","fluid-release","Fluid Framework client release group — minor releases, patch releases, and post-release type test updates. Covers release prep, branching, version bumps, changelogs, release notes, and type test baselines. In autonomous mode, auto-detects state from the repo, attempts to execute, and falls back to a GitHub issue on failure. Triggers on \"release\", \"do the release\", \"release status\", version bump, release notes, changelog, release branch, or release engineering.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002FSKILL.md",[],[183,184,185,35,39,186,187,188,189,190,37,191,192,193,194,195,196,197,198,199],"release","fluid release","fluid","bump","mode","autonomous","release notes","release status","updates","patch","notes","changelog","release prep","releases","status","issue","branching",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":44},"01M6PJ4VZB32S8YG8RBKRZ4GP2","fluid-pr","Use when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on \"create a PR\", \"make a PR\", \"open a PR\", \"submit a PR\", or \"push and create a PR\".","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-pr\u002FSKILL.md",[],[27,185,207,128,39,208,209,210,211,212,213,97,214,215,216,217,218,127,219,220,101],"fluid pr","push","submit","repo","triggers","pr title","open","fluid framework","create","title","github","pull request","conventions","body"]