[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BWFY5GMBEYDW4FKCXDCW2":3,"skill-same:01M69BWFY5GMBEYDW4FKCXDCW2":108},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":25,"commitSha":32,"skillDirectory":33,"forksCount":34,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":38,"updatedAt":39,"install":40,"resources":53},"01M69BWFY5GMBEYDW4FKCXDCW2","cherry-pick-to-release",null,"Cherry-pick a merged main-branch PR onto a MsQuic release branch (release\u002FX.Y).","microsoft\u002Fmsquic","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BWC6ERMDEB0EH4Q14J4KQ",4794,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmsquic\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcherry-pick-to-release\u002FSKILL.md",[],[19,20,21,22,23,24,25,26],"cherry pick","release","cherry pick to release","pick","pr","branch","main","branch pr","2026-11-10 10:12:30",false,"---\nname: cherry-pick-to-release\ndescription: 'Cherry-pick a merged main-branch PR onto a MsQuic release branch (release\u002FX.Y).'\n---\n\n# Cherry-Pick to MsQuic Release Branch\n\nYou are helping a maintainer back-port a fix from `main` to one or more\nMsQuic release branches (`release\u002F2.4`, `release\u002F2.5`, etc.).\n\nThis skill encodes the patterns the project uses.\n\n## When This Skill Activates\n\nThe user asks to cherry-pick \u002F back-port \u002F \"CP\" a PR or commit from `main`\nonto a release branch. Typical requests:\n\n- \"Cherry-pick #5942 to release\u002F2.4 and release\u002F2.5\"\n- \"Back-port the ACK underflow fix to 2.5\"\n- \"CP this commit to the 2.4 release branch\"\n\n## Inputs You Need\n\nBefore doing anything, make sure you know:\n\n1. **Source**: a PR number on `main` (preferred) or a commit SHA on `origin\u002Fmain`.\n2. **Target release branch(es)**: e.g. `release\u002F2.4`, `release\u002F2.5`. If the\n   user is ambiguous (e.g. \"to the release branches\"), ask whether they want\n   one branch or both, and which.\n3. **Whether to push \u002F open a PR**. You must never push a branch or open a PR\n   without explicit permission. Stop and ask before any `git push` or `gh pr create`.\n\nIf anything is missing, ask before proceeding.\n\n## Project Conventions (must follow)\n\n### PR Title\n\n```\n[CP] \u003COriginal PR title> (#\u003Coriginal_pr_number>)\n```\n\nExamples actually used on the release branches:\n\n- `[CP] Fix underflow in ACK frame parsing #5942`            (→ PR #5943 on 2.5, #5944 on 2.4)\n- `[CP] Fix SAL annotation placement on function templates (#5895)`\n- `[CP] Free AES 256 GCM algorithm handle on cleanup (#5526)`\n- `[CP] Fix double deref in connection pool error path (#5597)`\n\nWhen the same fix targets multiple release branches, the title is identical\nacross PRs; only the target branch differs. After squash-merge, GitHub\nappends the new PR number, producing commits like\n`[CP] Fix underflow in ACK frame parsing #5942 (#5943)` on the release\nbranch — this is expected and required (it makes traceability trivial).\n\nDo **not** invent new prefixes; stick to `[CP]` unless asked.\n\n### PR Body\n\n**Use the exact body of the original PR, verbatim**, including the\n`## Description`, `## Testing`, and `## Documentation` sections as the\noriginal author wrote them. Do **not** rewrite, summarize, or augment them\nwith cherry-pick commentary.\n\nNo additions or modification of the original description is acceptable.\n\n### Branch Naming\n\nProject convention (observed on most recent cherry-pick PRs):\n\n```\n\u003Cuser>\u002Fcp_\u003Cshort_description>_\u003Ctarget_version>_copilot\n```\n\nThe `\u003Cshort_description>` is a snake_case summary of the fix, mirroring\nprior branches like `cp_conn_pool_deref`, `cp_free_aes_256_gcm_handle`,\n`underflow_fix_cp`.\n\nUse one branch per target release branch (do not try to land both\nrelease branches from a single branch \u002F PR).\n\n### Commits Inside the PR\n\n- Almost always **one commit** — the cherry-picked commit, with its\n  original message preserved.\n- Occasionally a **second commit** is acceptable if needed to make the\n  release branch build\u002Fpass tests (merge conflict resolutions and build fixes).\n  Keep these tightly scoped to enabling the cherry-pick; do **not** sneak in unrelated changes.\n- Squash-merge erases the multi-commit structure on the release branch.\n- Do **not** add `(cherry picked from commit X)` trailers — the project\n  doesn't use `git cherry-pick -x`; traceability comes from the PR title\n  containing the original PR number.\n\n## Workflow\n\nFollow these steps in order. Do not skip a phase.\n\n### Phase 1 — Identify the source commit on main\n\n1. If given a PR number, find its squash-merge commit on `origin\u002Fmain`:\n   ```powershell\n   gh pr view \u003Corig_pr> --repo microsoft\u002Fmsquic --json mergeCommit,state,title,body,baseRefName\n   ```\n   Verify `state == MERGED` and `baseRefName == main`. If not merged, stop and tell the user — never cherry-pick an unmerged change.\n2. If given a SHA, confirm it is reachable from `origin\u002Fmain`:\n   ```powershell\n   git --no-pager log -1 --format=\"%H %s\" \u003Csha>\n   git --no-pager branch -r --contains \u003Csha> | Select-String \"origin\u002Fmain\"\n   ```\n3. Capture the original PR title and body — you'll reuse them.\n\n### Phase 2 — Prepare the local branch\n\nRepeat for each target release branch.\n\n1. Make sure the working tree is clean (`git status`). If not, stop and ask.\n2. Fetch latest refs: `git fetch origin --prune`.\n3. Create the branch from the tip of the release branch:\n   ```powershell\n   git checkout -b \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot origin\u002Frelease\u002F2.5\n   ```\n\n### Phase 3 — Apply the cherry-pick\n\n1. Run `git cherry-pick \u003Ccommit_sha>` (no `-x`).\n2. **On conflicts**:\n   - Resolve them, keeping the spirit of the original fix.\n   - If the conflict is non-trivial, briefly summarize the resolution in the PR body under `## Description` so reviewers know what differs from `main`.\n   - If the fix depends on code that doesn't exist on the release branch, **stop and ask the user** how to proceed (skip, adapt, or pull in additional commits) — do not silently rewrite the fix.\n\n### Phase 4 — Regenerate derived files (only if applicable)\n\nCheck whether the cherry-pick touches things that require regeneration. CI\nwill fail otherwise (`check-clog.yml`, `check-dotnet.yml`).\n\n- **Trace \u002F log macro changes** (`QuicTraceLogInfo`, `QuicTraceEvent`,\n  etc., or anything under `src\u002Fmanifest\u002F`):\n  ```powershell\n  .\u002Fscripts\u002Fupdate-sidecar.ps1\n  ```\n  Commit any changes under `src\u002Fgenerated\u002F` and `src\u002Fmanifest\u002Fclog.sidecar` as part of the same commit (or amend).\n\n- **Public C API surface changes** (anything under `src\u002Finc\u002F`, especially `msquic.h`):\n  ```powershell\n  .\u002Fscripts\u002Fgenerate-dotnet.ps1\n  ```\n  Commit any changes under `src\u002Fcs\u002F`.\n\nIf neither applies, skip this phase.\n\n### Phase 5 — Build and run tests locally (REQUIRED)\n\nBuild and run tests locally before pushing. This is **required for every\ncherry-pick**, regardless of whether the `git cherry-pick` was clean or\nrequired conflict resolution. Do not skip this phase.\n\n1. **Build** with the default TLS provider for the platform you're on:\n   ```powershell\n   .\u002Fscripts\u002Fbuild.ps1 -Tls schannel    # Windows\n   pwsh .\u002Fscripts\u002Fbuild.ps1 -Tls openssl # Linux\n   ```\n\n2. **Run the tests that exercise the cherry-picked code.** Use a\n   GoogleTest `--Filter` to keep the runtime short:\n   ```powershell\n   .\u002Fscripts\u002Ftest.ps1 -Tls schannel -Filter '\u003CTestSuite>.\u003CTestPattern>*'\n   ```\n   At minimum, run:\n   - the tests that were added or modified by the cherry-pick, and\n   - the tests directly covering the changed code paths (e.g.\n     `TlsTest.*` for `src\u002Fplatform\u002Ftls_*`, `ApiTest.*` for `src\u002Finc\u002F`\n     surface changes, `HandshakeTest.*` for `src\u002Fcore\u002F` handshake logic).\n\n3. If the build or the relevant tests fail on the release branch but\n   pass on `main`, **stop and ask the user** — do not push a broken\n   cherry-pick. Likely causes: missing prerequisite commits, API drift\n   between branches, or test infra changes that didn't get back-ported.\n\nCapture the build and test outcome (pass\u002Ffail, number of tests run) to\nmention briefly when you ask for permission to push.\n\n### Phase 6 — Push and open the PR (gated on explicit user permission)\n\nStop here and show a summary of the cherry-pick to the user:\noriginal PR, target branch, branch name, PR title, build and test status.\nConfirm with the user before pushing. Then:\n\n1. Push the branch:\n   ```powershell\n   git push -u origin \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot\n   ```\n2. Open the PR as a **draft** (per the user's standing rule, unless they say otherwise):\n   ```powershell\n   gh pr create --repo microsoft\u002Fmsquic `\n     --base release\u002F2.5 `\n     --head \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot `\n     --draft `\n     --title \"[CP] \u003COriginal title> (#\u003Corig_pr>)\" `\n     --body-file \u003Cpath_to_body.md>\n   ```\n   - `--base` must be the release branch (`release\u002F2.4`, `release\u002F2.5`, …), **not** `main`.\n3. If cherry-picking to multiple release branches, repeat phases 2–6 for each branch. Open one PR per branch; mention the sibling PR number in each body so reviewers can correlate them (e.g. `Companion PR for release\u002F2.4: #5944`).\n\n## Self-Verification Checklist\n\nBefore telling the user the cherry-pick is ready:\n\n- [ ] PR `--base` is the correct `release\u002FX.Y` branch (never `main`).\n- [ ] PR title is `[CP] \u003Corig title> (#\u003Corig_pr>)` (or an explicitly approved variant).\n- [ ] PR body uses the **exact body of the original PR verbatim** with no additions.\n- [ ] Branch name follows `\u003Cuser>\u002Fcp_\u003Cshort_desc>_\u003CX_Y>_copilot`.\n- [ ] PR is opened as a draft.\n- [ ] Only the cherry-picked commit (+ optional minimal build-fix commits) is on the branch — no unrelated changes.\n- [ ] **Local build succeeded** on the release branch with the cherry-pick applied (Phase 5).\n- [ ] **Relevant tests were run locally and pass** (Phase 5). The exact test filter and result are mentioned when asking the user for permission to push.\n- [ ] If trace\u002Flog macros were touched → `scripts\u002Fupdate-sidecar.ps1` was run and generated files committed.\n- [ ] If `src\u002Finc\u002F` public headers were touched → `scripts\u002Fgenerate-dotnet.ps1` was run and generated files committed.\n- [ ] You obtained explicit user permission before pushing and opening the PR.\n\n## Anti-Patterns to Avoid\n\n- **Don't** cherry-pick a PR that isn't merged on `main` yet.\n- **Don't** use `git cherry-pick -x` — the project doesn't include\n  `(cherry picked from commit X)` trailers in the final commit message.\n- **Don't** bundle unrelated fixes into the same cherry-pick PR. If you\n  see a related-but-distinct issue, open a separate cherry-pick.\n- **Don't** invent a new title prefix (e.g. `[BACKPORT 2.5]`) — stick to\n  `[CP]` to stay consistent with the last ~2 years of cherry-pick PRs.\n- **Don't** silently drop test changes.\n- **Don't** rewrite, summarize, or paraphrase the original PR's\n  description. The body must contain the original PR's body verbatim without additions.\n- **Don't** skip the local build \u002F test step (Phase 5), even when the\n  cherry-pick applied with no conflicts. Auto-merged hunks can still\n  produce subtly wrong code.\n- **Don't** push or open a PR without explicit user permission.\n- **Don't** bump the version number as part of a cherry-pick PR —\n  version bumps (`Bump version to v2.5.X`) are separate PRs done at\n  release time.\n\n## Non-Goals\n\n- Triaging whether a fix *should* be cherry-picked. The user decides\n  that; this skill just executes the cherry-pick cleanly.\n- Releasing \u002F tagging \u002F publishing artifacts. Those are separate\n  processes handled outside this skill.\n","# Cherry-Pick to MsQuic Release Branch\n\nYou are helping a maintainer back-port a fix from `main` to one or more\nMsQuic release branches (`release\u002F2.4`, `release\u002F2.5`, etc.).\n\nThis skill encodes the patterns the project uses.\n\n## When This Skill Activates\n\nThe user asks to cherry-pick \u002F back-port \u002F \"CP\" a PR or commit from `main`\nonto a release branch. Typical requests:\n\n- \"Cherry-pick #5942 to release\u002F2.4 and release\u002F2.5\"\n- \"Back-port the ACK underflow fix to 2.5\"\n- \"CP this commit to the 2.4 release branch\"\n\n## Inputs You Need\n\nBefore doing anything, make sure you know:\n\n1. **Source**: a PR number on `main` (preferred) or a commit SHA on `origin\u002Fmain`.\n2. **Target release branch(es)**: e.g. `release\u002F2.4`, `release\u002F2.5`. If the\n   user is ambiguous (e.g. \"to the release branches\"), ask whether they want\n   one branch or both, and which.\n3. **Whether to push \u002F open a PR**. You must never push a branch or open a PR\n   without explicit permission. Stop and ask before any `git push` or `gh pr create`.\n\nIf anything is missing, ask before proceeding.\n\n## Project Conventions (must follow)\n\n### PR Title\n\n```\n[CP] \u003COriginal PR title> (#\u003Coriginal_pr_number>)\n```\n\nExamples actually used on the release branches:\n\n- `[CP] Fix underflow in ACK frame parsing #5942`            (→ PR #5943 on 2.5, #5944 on 2.4)\n- `[CP] Fix SAL annotation placement on function templates (#5895)`\n- `[CP] Free AES 256 GCM algorithm handle on cleanup (#5526)`\n- `[CP] Fix double deref in connection pool error path (#5597)`\n\nWhen the same fix targets multiple release branches, the title is identical\nacross PRs; only the target branch differs. After squash-merge, GitHub\nappends the new PR number, producing commits like\n`[CP] Fix underflow in ACK frame parsing #5942 (#5943)` on the release\nbranch — this is expected and required (it makes traceability trivial).\n\nDo **not** invent new prefixes; stick to `[CP]` unless asked.\n\n### PR Body\n\n**Use the exact body of the original PR, verbatim**, including the\n`## Description`, `## Testing`, and `## Documentation` sections as the\noriginal author wrote them. Do **not** rewrite, summarize, or augment them\nwith cherry-pick commentary.\n\nNo additions or modification of the original description is acceptable.\n\n### Branch Naming\n\nProject convention (observed on most recent cherry-pick PRs):\n\n```\n\u003Cuser>\u002Fcp_\u003Cshort_description>_\u003Ctarget_version>_copilot\n```\n\nThe `\u003Cshort_description>` is a snake_case summary of the fix, mirroring\nprior branches like `cp_conn_pool_deref`, `cp_free_aes_256_gcm_handle`,\n`underflow_fix_cp`.\n\nUse one branch per target release branch (do not try to land both\nrelease branches from a single branch \u002F PR).\n\n### Commits Inside the PR\n\n- Almost always **one commit** — the cherry-picked commit, with its\n  original message preserved.\n- Occasionally a **second commit** is acceptable if needed to make the\n  release branch build\u002Fpass tests (merge conflict resolutions and build fixes).\n  Keep these tightly scoped to enabling the cherry-pick; do **not** sneak in unrelated changes.\n- Squash-merge erases the multi-commit structure on the release branch.\n- Do **not** add `(cherry picked from commit X)` trailers — the project\n  doesn't use `git cherry-pick -x`; traceability comes from the PR title\n  containing the original PR number.\n\n## Workflow\n\nFollow these steps in order. Do not skip a phase.\n\n### Phase 1 — Identify the source commit on main\n\n1. If given a PR number, find its squash-merge commit on `origin\u002Fmain`:\n   ```powershell\n   gh pr view \u003Corig_pr> --repo microsoft\u002Fmsquic --json mergeCommit,state,title,body,baseRefName\n   ```\n   Verify `state == MERGED` and `baseRefName == main`. If not merged, stop and tell the user — never cherry-pick an unmerged change.\n2. If given a SHA, confirm it is reachable from `origin\u002Fmain`:\n   ```powershell\n   git --no-pager log -1 --format=\"%H %s\" \u003Csha>\n   git --no-pager branch -r --contains \u003Csha> | Select-String \"origin\u002Fmain\"\n   ```\n3. Capture the original PR title and body — you'll reuse them.\n\n### Phase 2 — Prepare the local branch\n\nRepeat for each target release branch.\n\n1. Make sure the working tree is clean (`git status`). If not, stop and ask.\n2. Fetch latest refs: `git fetch origin --prune`.\n3. Create the branch from the tip of the release branch:\n   ```powershell\n   git checkout -b \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot origin\u002Frelease\u002F2.5\n   ```\n\n### Phase 3 — Apply the cherry-pick\n\n1. Run `git cherry-pick \u003Ccommit_sha>` (no `-x`).\n2. **On conflicts**:\n   - Resolve them, keeping the spirit of the original fix.\n   - If the conflict is non-trivial, briefly summarize the resolution in the PR body under `## Description` so reviewers know what differs from `main`.\n   - If the fix depends on code that doesn't exist on the release branch, **stop and ask the user** how to proceed (skip, adapt, or pull in additional commits) — do not silently rewrite the fix.\n\n### Phase 4 — Regenerate derived files (only if applicable)\n\nCheck whether the cherry-pick touches things that require regeneration. CI\nwill fail otherwise (`check-clog.yml`, `check-dotnet.yml`).\n\n- **Trace \u002F log macro changes** (`QuicTraceLogInfo`, `QuicTraceEvent`,\n  etc., or anything under `src\u002Fmanifest\u002F`):\n  ```powershell\n  .\u002Fscripts\u002Fupdate-sidecar.ps1\n  ```\n  Commit any changes under `src\u002Fgenerated\u002F` and `src\u002Fmanifest\u002Fclog.sidecar` as part of the same commit (or amend).\n\n- **Public C API surface changes** (anything under `src\u002Finc\u002F`, especially `msquic.h`):\n  ```powershell\n  .\u002Fscripts\u002Fgenerate-dotnet.ps1\n  ```\n  Commit any changes under `src\u002Fcs\u002F`.\n\nIf neither applies, skip this phase.\n\n### Phase 5 — Build and run tests locally (REQUIRED)\n\nBuild and run tests locally before pushing. This is **required for every\ncherry-pick**, regardless of whether the `git cherry-pick` was clean or\nrequired conflict resolution. Do not skip this phase.\n\n1. **Build** with the default TLS provider for the platform you're on:\n   ```powershell\n   .\u002Fscripts\u002Fbuild.ps1 -Tls schannel    # Windows\n   pwsh .\u002Fscripts\u002Fbuild.ps1 -Tls openssl # Linux\n   ```\n\n2. **Run the tests that exercise the cherry-picked code.** Use a\n   GoogleTest `--Filter` to keep the runtime short:\n   ```powershell\n   .\u002Fscripts\u002Ftest.ps1 -Tls schannel -Filter '\u003CTestSuite>.\u003CTestPattern>*'\n   ```\n   At minimum, run:\n   - the tests that were added or modified by the cherry-pick, and\n   - the tests directly covering the changed code paths (e.g.\n     `TlsTest.*` for `src\u002Fplatform\u002Ftls_*`, `ApiTest.*` for `src\u002Finc\u002F`\n     surface changes, `HandshakeTest.*` for `src\u002Fcore\u002F` handshake logic).\n\n3. If the build or the relevant tests fail on the release branch but\n   pass on `main`, **stop and ask the user** — do not push a broken\n   cherry-pick. Likely causes: missing prerequisite commits, API drift\n   between branches, or test infra changes that didn't get back-ported.\n\nCapture the build and test outcome (pass\u002Ffail, number of tests run) to\nmention briefly when you ask for permission to push.\n\n### Phase 6 — Push and open the PR (gated on explicit user permission)\n\nStop here and show a summary of the cherry-pick to the user:\noriginal PR, target branch, branch name, PR title, build and test status.\nConfirm with the user before pushing. Then:\n\n1. Push the branch:\n   ```powershell\n   git push -u origin \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot\n   ```\n2. Open the PR as a **draft** (per the user's standing rule, unless they say otherwise):\n   ```powershell\n   gh pr create --repo microsoft\u002Fmsquic `\n     --base release\u002F2.5 `\n     --head \u003Cuser>\u002Fcp_\u003Cshort_desc>_2_5_copilot `\n     --draft `\n     --title \"[CP] \u003COriginal title> (#\u003Corig_pr>)\" `\n     --body-file \u003Cpath_to_body.md>\n   ```\n   - `--base` must be the release branch (`release\u002F2.4`, `release\u002F2.5`, …), **not** `main`.\n3. If cherry-picking to multiple release branches, repeat phases 2–6 for each branch. Open one PR per branch; mention the sibling PR number in each body so reviewers can correlate them (e.g. `Companion PR for release\u002F2.4: #5944`).\n\n## Self-Verification Checklist\n\nBefore telling the user the cherry-pick is ready:\n\n- [ ] PR `--base` is the correct `release\u002FX.Y` branch (never `main`).\n- [ ] PR title is `[CP] \u003Corig title> (#\u003Corig_pr>)` (or an explicitly approved variant).\n- [ ] PR body uses the **exact body of the original PR verbatim** with no additions.\n- [ ] Branch name follows `\u003Cuser>\u002Fcp_\u003Cshort_desc>_\u003CX_Y>_copilot`.\n- [ ] PR is opened as a draft.\n- [ ] Only the cherry-picked commit (+ optional minimal build-fix commits) is on the branch — no unrelated changes.\n- [ ] **Local build succeeded** on the release branch with the cherry-pick applied (Phase 5).\n- [ ] **Relevant tests were run locally and pass** (Phase 5). The exact test filter and result are mentioned when asking the user for permission to push.\n- [ ] If trace\u002Flog macros were touched → `scripts\u002Fupdate-sidecar.ps1` was run and generated files committed.\n- [ ] If `src\u002Finc\u002F` public headers were touched → `scripts\u002Fgenerate-dotnet.ps1` was run and generated files committed.\n- [ ] You obtained explicit user permission before pushing and opening the PR.\n\n## Anti-Patterns to Avoid\n\n- **Don't** cherry-pick a PR that isn't merged on `main` yet.\n- **Don't** use `git cherry-pick -x` — the project doesn't include\n  `(cherry picked from commit X)` trailers in the final commit message.\n- **Don't** bundle unrelated fixes into the same cherry-pick PR. If you\n  see a related-but-distinct issue, open a separate cherry-pick.\n- **Don't** invent a new title prefix (e.g. `[BACKPORT 2.5]`) — stick to\n  `[CP]` to stay consistent with the last ~2 years of cherry-pick PRs.\n- **Don't** silently drop test changes.\n- **Don't** rewrite, summarize, or paraphrase the original PR's\n  description. The body must contain the original PR's body verbatim without additions.\n- **Don't** skip the local build \u002F test step (Phase 5), even when the\n  cherry-pick applied with no conflicts. Auto-merged hunks can still\n  produce subtly wrong code.\n- **Don't** push or open a PR without explicit user permission.\n- **Don't** bump the version number as part of a cherry-pick PR —\n  version bumps (`Bump version to v2.5.X`) are separate PRs done at\n  release time.\n\n## Non-Goals\n\n- Triaging whether a fix *should* be cherry-picked. The user decides\n  that; this skill just executes the cherry-pick cleanly.\n- Releasing \u002F tagging \u002F publishing artifacts. Those are separate\n  processes handled outside this skill.\n",{"name":5,"description":7},"f2ab3147945a8bbaae4acad7f66e00783a47ec19",".github\u002Fskills\u002Fcherry-pick-to-release",728,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmsquic","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 17:37:34",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add microsoft\u002Fmsquic --skill cherry-pick-to-release",{"tool":46,"command":47},"bunx","bunx skills add microsoft\u002Fmsquic --skill cherry-pick-to-release",{"tool":49,"command":50},"pnpm","pnpm dlx skills add microsoft\u002Fmsquic --skill cherry-pick-to-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmsquic\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcherry-pick-to-release\u002FSKILL.md",true,[54,60,64,68,72,76,82,86,90,96,100,104],{"path":55,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":58,"sourceHtmlUrl":59},"assets\u002Ftemplates\u002Farchitecture.drawio","ASSET","资产文件",8077,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fassets\u002Ftemplates\u002Farchitecture.drawio",{"path":61,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":62,"sourceHtmlUrl":63},"assets\u002Ftemplates\u002Fer-diagram.drawio",26593,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fassets\u002Ftemplates\u002Fer-diagram.drawio",{"path":65,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":66,"sourceHtmlUrl":67},"assets\u002Ftemplates\u002Fflowchart.drawio",4590,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fassets\u002Ftemplates\u002Fflowchart.drawio",{"path":69,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":70,"sourceHtmlUrl":71},"assets\u002Ftemplates\u002Fsequence.drawio",7290,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fassets\u002Ftemplates\u002Fsequence.drawio",{"path":73,"resourceType":56,"resourceTypeDesc":57,"sizeBytes":74,"sourceHtmlUrl":75},"assets\u002Ftemplates\u002Fuml-class.drawio",12960,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fassets\u002Ftemplates\u002Fuml-class.drawio",{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fdrawio-xml-schema.md","REFERENCE","参考文档",10796,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Freferences\u002Fdrawio-xml-schema.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fshape-libraries.md",13126,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Freferences\u002Fshape-libraries.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fstyle-reference.md",15491,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Freferences\u002Fstyle-reference.md",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"scripts\u002F.gitignore","SCRIPT","脚本",39,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fscripts\u002F.gitignore",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fadd-shape.py",6642,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fscripts\u002Fadd-shape.py",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002FREADME.md",3332,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fscripts\u002FREADME.md",{"path":105,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":106,"sourceHtmlUrl":107},"scripts\u002Fvalidate-drawio.py",7643,"https:\u002F\u002Fgithub.com\u002Fgithub\u002Fawesome-copilot\u002Fblob\u002Fmain\u002Fskills\u002Fdraw-io-diagram-generator\u002Fscripts\u002Fvalidate-drawio.py",[109],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":27},"01M69BWJNSWYKY2M0XQS545RJX","investigate-ci-failure","Guide systematic investigation of MsQuic CI test failures reported by GitHub Actions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fmsquic\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Finvestigate-ci-failure\u002FSKILL.md",[],[116,117,118,119,120,121,122,123,124,125,126],"investigate ci failure","ci","investigate","github","test","actions","github actions","investigation","guide","systematic","ci test failures"]