[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699ACSSS4DW81KHV83A3NWQ":3,"skill-same:01M699ACSSS4DW81KHV83A3NWQ":60},{"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":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":41,"ownerHtmlUrl":42,"ownerBlogUrl":43,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M699ACSSS4DW81KHV83A3NWQ","experiments",null,"Use when adding, changing, or reviewing a VS Code A\u002FB experiment, either an experiment-controlled setting or a treatment read with the assignment service, and when deciding whether and where to log an `experimentTrigger` event for a triggered ExP scorecard.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195270,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fexperiments\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30],"scorecard","for","event","use","either","code","log","with","read","service","experiment","when","2026-11-10 10:12:30",false,"---\nname: experiments\ndescription: Use when adding, changing, or reviewing a VS Code A\u002FB experiment, either an experiment-controlled setting or a treatment read with the assignment service, and when deciding whether and where to log an `experimentTrigger` event for a triggered ExP scorecard.\n---\n\n# Experiments\n\n## Controlling behavior\n\n- **Experiment-controlled setting:** add `experiment: { mode: 'auto' }` to the setting's schema, or `mode: 'startup'` to only pick up changed assignments on startup. ExP then sets the setting's default through the treatment `config.\u003Csetting id>` (or `experiment.name`), and code reads the setting with `IConfigurationService` as usual. Values that users set themselves still win. Use this when users could reasonably choose the behavior themselves.\n- **Keyed object setting:** treatments can't be objects, so to let separate experiments control separate keys of an object setting, such as one experiment per extension, add `keyed: true` to its `experiment`. ExP then sets each key's default through the treatment `config.\u003Csetting id>.\u003Ckey>`, and the mode applies to each key separately. Treatments can't be enumerated, so a key is only resolved once code requests it with `IExperimentalSettingsService.requestKeys`. Values that users set for a key still win.\n- **Treatment:** read a value with `IWorkbenchAssignmentService.getTreatment\u003CT>(name)`. It resolves to `undefined` without an assignment, so keep a fallback, and read it again on `onDidRefetchAssignments`. Use this for values that are not user preferences, such as copy or variant names.\n\nTo try an assignment locally, set `experiments.override.\u003Ctreatment name>` in your user settings, for example `\"experiments.override.config.chat.mySetting.enabled\": true`.\n\n## Assignment routing\n\nInitialize the core TAS client, cached treatments, and legacy fetching immediately; only new-TAS routing waits for account discovery. A known account can be routed before account initialization completes, but a null account is ambiguous until then. Rebuild the client for an account change only when the old or new routing uses a new-TAS endpoint. Confirmed signed-out sessions, including those configured for GitHub Enterprise\u002FGHES, start with `https:\u002F\u002Fexp.enterprise.githubcopilot.com`, then `https:\u002F\u002Fexp.business.githubcopilot.com`, then `https:\u002F\u002Fexp.individual.githubcopilot.com` (each with `\u002Fapi\u002Fv1\u002Fassignments`). These device-only requests overlap only during discovery: launch the next host after 1 second without a valid result, or sooner on a network error, non-success HTTP status, or invalid assignments response. Try each host at most once per fetch, with a single 5-second deadline for the entire discovery. The first valid response wins (including empty assignments); cancel outstanding requests and pending launches. Remember the winning host for the window and try it first on subsequent refreshes without time-based hedging; it fails over only on an error. If the remembered host times out, forget it so the next fetch rediscovers with hedging. If all fail or the deadline expires, reject the provider fetch and retry on the existing refresh schedule. Because tas-client waits for all providers, discovery can delay treatment reads that miss the cache by up to the deadline. Cancellation of a pending request depends on the transport; with the default Copilot Node `https` fetcher, an unanswered losing request can stay open until its socket times out, but its result is ignored. Signed-in accounts never cycle: explicit `exp` remains authoritative, and only confirmed public individual accounts without `exp` use Individual. Signed-in Business, Enterprise, GHE\u002FGHES, and accounts with unknown plans require explicit `exp`; core relies on account-provider updates and its staleness-aware polling, without forcing entitlement requests from assignment refreshes. Copilot re-evaluates routing and both legacy\u002Fnew targeting on auth\u002Ftoken-data updates, including metadata changes with an unchanged bearer token. The existing token-string event retains its original semantics. Never infer sign-out from a missing token, retain account filters across sign-out, or send cached account identity during anonymous discovery. New assignments still merge with legacy TAS during the transition; legacy is not the routing solution for a missing managed-account endpoint.\n\nClassic vscode.dev without a remote intentionally does not initialize its default-account provider. Core therefore uses device-only discovery there even if another feature has a GitHub session; null account state is not proof of actual sign-out in that environment. Browser TAS requests require the workbench's Content Security Policy (CSP) `connect-src` to allow all three discovery hosts, and each endpoint must support CORS for the page's origin.\n\nCore product experimentation intentionally remains governed by the existing telemetry and experimentation controls, not `chat.disableAIFeatures`. Disabling AI UI does not disable these device-level TAS requests; disabling experiments or the required telemetry level does. Legacy startup\u002Fcache results may be consumed before account-specific new assignments arrive, preserving the existing startup behavior rather than gating all experiment lookups on authentication.\n\n## Trigger events for triggered scorecards\n\nA triggered scorecard only compares users who reached the moment where control and treatment behave differently, so users that the experiment never affected don't dilute the result. Log that moment with the helpers in [experimentTrigger.ts](..\u002F..\u002F..\u002Fsrc\u002Fvs\u002Fplatform\u002Ftelemetry\u002Fcommon\u002FexperimentTrigger.ts):\n\n```ts\nlogSettingExperimentTrigger(telemetryService, MY_SETTING_ID); \u002F\u002F experiment-controlled setting\nlogSettingKeyExperimentTrigger(telemetryService, MY_SETTING_ID, key); \u002F\u002F key of a keyed object setting\nlogExperimentTrigger(telemetryService, 'myTreatment'); \u002F\u002F treatment\n```\n\nThey log the shared `experimentTrigger` event with the treatment name as `treatmentName`, at most once per window or process, so they can run on every evaluation. Base the scorecard's trigger on that event (`monacoworkbench\u002FexperimentTrigger`) and its `treatmentName`. Don't add feature-specific trigger events.\n\n### When to use one\n\nUse a trigger when only some assigned users are affected, at an identifiable moment: an action, a surface that only appears in some situations, or a code path that only some sessions reach. Don't use one when:\n\n- nearly every assigned user is affected anyway, like a changed default in a common view;\n- no single moment precedes every effect, like a feature switch that also changes commands or agent tools before anything is visible (`chat.agentMerge.enabled`);\n- the population is already limited: onboarding experiments (`IOnboardingScenario.experiment`) only attach their assignment context to telemetry from the moment the tour would show.\n\nPrefer no trigger over an approximate one. Dilution only costs statistical power, while a biased trigger gives wrong results.\n\n### When to fire it\n\nFire it where the code decides between control and treatment behavior, before they differ, under a condition that is the same in every arm.\n\n| The treatment… | Fire when… |\n|---|---|\n| changes what an action does | the action runs |\n| adds UI that control lacks | the UI would render, checked in every arm |\n| changes copy or an icon | that UI renders |\n| changes a delay | the countdown starts, not when the delayed UI shows |\n| changes a default that users can override | the default is visible and no user choice is stored |\n| changes background behavior | the diverging code path runs |\n\n```ts\n\u002F\u002F Checking the setting first would only trigger the treatment arm.\nif (isBannerRelevant(context)) {\n\tlogSettingExperimentTrigger(telemetryService, MY_SETTING_ID);\n\tif (configurationService.getValue\u003Cboolean>(MY_SETTING_ID)) {\n\t\tshowBanner();\n\t}\n}\n```\n\nCommon pitfalls:\n\n- **State only the treatment writes**, like dismissed or seen flags. Ignore it until the trigger has fired.\n- **Data only the treatment computes**, like CI status that is only polled for an indicator. Use an arm-independent superset, or compute it in every arm until the trigger has fired.\n- **Missed exposure**, like accessible labels, menus, or features that the setting suppresses. Find every place where the setting or treatment changes behavior, because a user affected before their first trigger biases the result.\n\nExcluding users who can't be affected, such as reduced-motion users for an animation, is fine when the condition is the same in every arm. Agent host telemetry only carries the assignment context once the workbench has forwarded it, so hold earlier triggers until then (see `AgentHostGitStateService`).\n\nTest each trigger in every arm with `TestExperimentTriggerTelemetryService`. After adding or moving a trigger, start a new experiment iteration, because earlier exposures have no trigger events.\n\n## Reporting results\n\nScorecard results are internal data. A pull request, commit or issue that ships, changes, graduates or removes an experiment describes only the code change. Don't explain the change with the experiment, its rollout or its results, even without numbers, such as \"the treatment improved the primary metric\" or \"the experiment showed no regression\"; link its tracking issue instead (see \"Public Content\" in [copilot-instructions.md](..\u002F..\u002Fcopilot-instructions.md)).\n","# Experiments\n\n## Controlling behavior\n\n- **Experiment-controlled setting:** add `experiment: { mode: 'auto' }` to the setting's schema, or `mode: 'startup'` to only pick up changed assignments on startup. ExP then sets the setting's default through the treatment `config.\u003Csetting id>` (or `experiment.name`), and code reads the setting with `IConfigurationService` as usual. Values that users set themselves still win. Use this when users could reasonably choose the behavior themselves.\n- **Keyed object setting:** treatments can't be objects, so to let separate experiments control separate keys of an object setting, such as one experiment per extension, add `keyed: true` to its `experiment`. ExP then sets each key's default through the treatment `config.\u003Csetting id>.\u003Ckey>`, and the mode applies to each key separately. Treatments can't be enumerated, so a key is only resolved once code requests it with `IExperimentalSettingsService.requestKeys`. Values that users set for a key still win.\n- **Treatment:** read a value with `IWorkbenchAssignmentService.getTreatment\u003CT>(name)`. It resolves to `undefined` without an assignment, so keep a fallback, and read it again on `onDidRefetchAssignments`. Use this for values that are not user preferences, such as copy or variant names.\n\nTo try an assignment locally, set `experiments.override.\u003Ctreatment name>` in your user settings, for example `\"experiments.override.config.chat.mySetting.enabled\": true`.\n\n## Assignment routing\n\nInitialize the core TAS client, cached treatments, and legacy fetching immediately; only new-TAS routing waits for account discovery. A known account can be routed before account initialization completes, but a null account is ambiguous until then. Rebuild the client for an account change only when the old or new routing uses a new-TAS endpoint. Confirmed signed-out sessions, including those configured for GitHub Enterprise\u002FGHES, start with `https:\u002F\u002Fexp.enterprise.githubcopilot.com`, then `https:\u002F\u002Fexp.business.githubcopilot.com`, then `https:\u002F\u002Fexp.individual.githubcopilot.com` (each with `\u002Fapi\u002Fv1\u002Fassignments`). These device-only requests overlap only during discovery: launch the next host after 1 second without a valid result, or sooner on a network error, non-success HTTP status, or invalid assignments response. Try each host at most once per fetch, with a single 5-second deadline for the entire discovery. The first valid response wins (including empty assignments); cancel outstanding requests and pending launches. Remember the winning host for the window and try it first on subsequent refreshes without time-based hedging; it fails over only on an error. If the remembered host times out, forget it so the next fetch rediscovers with hedging. If all fail or the deadline expires, reject the provider fetch and retry on the existing refresh schedule. Because tas-client waits for all providers, discovery can delay treatment reads that miss the cache by up to the deadline. Cancellation of a pending request depends on the transport; with the default Copilot Node `https` fetcher, an unanswered losing request can stay open until its socket times out, but its result is ignored. Signed-in accounts never cycle: explicit `exp` remains authoritative, and only confirmed public individual accounts without `exp` use Individual. Signed-in Business, Enterprise, GHE\u002FGHES, and accounts with unknown plans require explicit `exp`; core relies on account-provider updates and its staleness-aware polling, without forcing entitlement requests from assignment refreshes. Copilot re-evaluates routing and both legacy\u002Fnew targeting on auth\u002Ftoken-data updates, including metadata changes with an unchanged bearer token. The existing token-string event retains its original semantics. Never infer sign-out from a missing token, retain account filters across sign-out, or send cached account identity during anonymous discovery. New assignments still merge with legacy TAS during the transition; legacy is not the routing solution for a missing managed-account endpoint.\n\nClassic vscode.dev without a remote intentionally does not initialize its default-account provider. Core therefore uses device-only discovery there even if another feature has a GitHub session; null account state is not proof of actual sign-out in that environment. Browser TAS requests require the workbench's Content Security Policy (CSP) `connect-src` to allow all three discovery hosts, and each endpoint must support CORS for the page's origin.\n\nCore product experimentation intentionally remains governed by the existing telemetry and experimentation controls, not `chat.disableAIFeatures`. Disabling AI UI does not disable these device-level TAS requests; disabling experiments or the required telemetry level does. Legacy startup\u002Fcache results may be consumed before account-specific new assignments arrive, preserving the existing startup behavior rather than gating all experiment lookups on authentication.\n\n## Trigger events for triggered scorecards\n\nA triggered scorecard only compares users who reached the moment where control and treatment behave differently, so users that the experiment never affected don't dilute the result. Log that moment with the helpers in [experimentTrigger.ts](..\u002F..\u002F..\u002Fsrc\u002Fvs\u002Fplatform\u002Ftelemetry\u002Fcommon\u002FexperimentTrigger.ts):\n\n```ts\nlogSettingExperimentTrigger(telemetryService, MY_SETTING_ID); \u002F\u002F experiment-controlled setting\nlogSettingKeyExperimentTrigger(telemetryService, MY_SETTING_ID, key); \u002F\u002F key of a keyed object setting\nlogExperimentTrigger(telemetryService, 'myTreatment'); \u002F\u002F treatment\n```\n\nThey log the shared `experimentTrigger` event with the treatment name as `treatmentName`, at most once per window or process, so they can run on every evaluation. Base the scorecard's trigger on that event (`monacoworkbench\u002FexperimentTrigger`) and its `treatmentName`. Don't add feature-specific trigger events.\n\n### When to use one\n\nUse a trigger when only some assigned users are affected, at an identifiable moment: an action, a surface that only appears in some situations, or a code path that only some sessions reach. Don't use one when:\n\n- nearly every assigned user is affected anyway, like a changed default in a common view;\n- no single moment precedes every effect, like a feature switch that also changes commands or agent tools before anything is visible (`chat.agentMerge.enabled`);\n- the population is already limited: onboarding experiments (`IOnboardingScenario.experiment`) only attach their assignment context to telemetry from the moment the tour would show.\n\nPrefer no trigger over an approximate one. Dilution only costs statistical power, while a biased trigger gives wrong results.\n\n### When to fire it\n\nFire it where the code decides between control and treatment behavior, before they differ, under a condition that is the same in every arm.\n\n| The treatment… | Fire when… |\n|---|---|\n| changes what an action does | the action runs |\n| adds UI that control lacks | the UI would render, checked in every arm |\n| changes copy or an icon | that UI renders |\n| changes a delay | the countdown starts, not when the delayed UI shows |\n| changes a default that users can override | the default is visible and no user choice is stored |\n| changes background behavior | the diverging code path runs |\n\n```ts\n\u002F\u002F Checking the setting first would only trigger the treatment arm.\nif (isBannerRelevant(context)) {\n\tlogSettingExperimentTrigger(telemetryService, MY_SETTING_ID);\n\tif (configurationService.getValue\u003Cboolean>(MY_SETTING_ID)) {\n\t\tshowBanner();\n\t}\n}\n```\n\nCommon pitfalls:\n\n- **State only the treatment writes**, like dismissed or seen flags. Ignore it until the trigger has fired.\n- **Data only the treatment computes**, like CI status that is only polled for an indicator. Use an arm-independent superset, or compute it in every arm until the trigger has fired.\n- **Missed exposure**, like accessible labels, menus, or features that the setting suppresses. Find every place where the setting or treatment changes behavior, because a user affected before their first trigger biases the result.\n\nExcluding users who can't be affected, such as reduced-motion users for an animation, is fine when the condition is the same in every arm. Agent host telemetry only carries the assignment context once the workbench has forwarded it, so hold earlier triggers until then (see `AgentHostGitStateService`).\n\nTest each trigger in every arm with `TestExperimentTriggerTelemetryService`. After adding or moving a trigger, start a new experiment iteration, because earlier exposures have no trigger events.\n\n## Reporting results\n\nScorecard results are internal data. A pull request, commit or issue that ships, changes, graduates or removes an experiment describes only the code change. Don't explain the change with the experiment, its rollout or its results, even without numbers, such as \"the treatment improved the primary metric\" or \"the experiment showed no regression\"; link its tracking issue instead (see \"Public Content\" in [copilot-instructions.md](..\u002F..\u002Fcopilot-instructions.md)).\n",{"name":5,"description":7},"main","6fef772036848fdba226014ed798eb1654b32c39",".github\u002Fskills\u002Fexperiments",43791,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode","https:\u002F\u002Fcode.visualstudio.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-12 03:13:10",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add microsoft\u002Fvscode --skill experiments",{"tool":52,"command":53},"bunx","bunx skills add microsoft\u002Fvscode --skill experiments",{"tool":55,"command":56},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill experiments","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fexperiments\u002FSKILL.md",true,[],[61,85,106,120,134,150],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":31},"01M70H0ANBKZAVEP1NVV4K28M3","sweeper-query","Answer natural-language questions about the VS Code Sweeper's published issue index (index-\u003Cname>.json for microsoft\u002Fvscode and the enrolled family repos) — which issues are agent-ready to implement or plan, what the sweeper proposed for an assignee or area, whether the sweeper knows a report as a duplicate, the highest-value open bugs in a lane — and, for one issue, the review's full record (evidence with file citations, fix brief, proposed comment). Use ONLY when the request explicitly names the sweeper — \"sweeper\", \"vscodesweeper\", \"sweeper-query\", a sweeper verdict, record, brief or index, an agent-ready issue — or asks what \"the sweeper\" found, proposed or knows. Do NOT use for general questions about issues, duplicates, priorities or ranking that do not mention the sweeper. Read-only; discovery only.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsweeper-query\u002FSKILL.md",[],[68,69,70,71,72,30,73,74,75,76,77,78,79,27,80,81,82,83,84,24],"sweeper query","query","sweeper","review","fix","request","which","natural-language","ranking","duplicates","ready","only","plan","open","Citations","brief","issues",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":31},"01M699DRJS4YJCV600Q72SVVWE","update-skills","Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says \"learn!\", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-skills\u002FSKILL.md",[],[92,93,20,94,95,96,97,22,98,99,100,101,102,103,104,105,30],"update","update skills","pattern","domain","learnings","reusable","session","user","instructions","knowledge","repository","learn","create","sessions",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":31},"01M699DPWHZ72B66P82EW31RNE","update-pr","Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-pr\u002FSKILL.md",[],[92,113,114,30,73,115,20,22,98,99,116,117,118,119],"pr","update pr","Existing","push","pull","pull request","changes",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":31},"01M699DJMR6CE1MH5XCJZ0GFQ0","sync","Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync\u002FSKILL.md",[],[122,127,128,116,117,129,30,119,130,26,131,132,22,98,99,133],"SET","publish","rebase","latest","remote","upstream","branch",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":31},"01M699DGXHX6A2A72X57R6GGHJ","sync-upstream","Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync-upstream\u002FSKILL.md",[],[132,122,141,142,30,143,144,119,130,145,146,147,148,22,98,133,149,92],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":31},"01M699DEXYFWDGW0BAXJ5QQ377","merge","Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fmerge\u002FSKILL.md",[],[152,98,22,149,133,99,30,157,158,119],"back","base"]