[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699B9N34AZSQ87SP8E4FP0F":3,"skill-same:01M699B9N34AZSQ87SP8E4FP0F":58},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M699B9N34AZSQ87SP8E4FP0F","sessions",null,"Core principles and workflow router for changes to the Agents Window under src\u002Fvs\u002Fsessions.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195347,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsessions\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28],"workflow","core","src","router","workflow router","core principles","principles","for","changes","window","2026-11-10 10:12:30",false,"---\nname: sessions\ndescription: Core principles and workflow router for changes to the Agents Window under src\u002Fvs\u002Fsessions.\n---\n\n# Agents Window development\n\nUse this skill for implementation, review, or design work under `src\u002Fvs\u002Fsessions\u002F**`.\n\n## 1. Apply the core principles\n\n- Preserve the layer direction: `vs\u002Fsessions` may import `vs\u002Fworkbench` and lower layers; `vs\u002Fworkbench` must never import `vs\u002Fsessions`.\n- Keep shared Sessions code provider-neutral. Non-provider contributions must not import provider implementations.\n- Model mutable session and chat state with observables. Use events for notifications, not as a parallel state model or for control flow.\n- Register Sessions menu IDs in `browser\u002Fmenus.ts` and consume `Menus.*`.\n- Import contributions from the appropriate `sessions.*.main.ts` entry point.\n- Prefer Sessions-owned adaptations over shared workbench changes unless the capability is genuinely shared.\n- Put stable architecture in the owning specification and concrete behavior in tests. Do not preserve implementation chronology as development guidance.\n\n## 2. Identify the owning area\n\nStart with `src\u002Fvs\u002Fsessions\u002FREADME.md`, then read only the specifications relevant to the change:\n\n| Area | Specification |\n|------|---------------|\n| Layering, folder ownership, cross-module imports | `src\u002Fvs\u002Fsessions\u002FLAYERS.md` |\n| Session\u002Fchat model, services, provider contract, core data flow | `src\u002Fvs\u002Fsessions\u002FSESSIONS.md` |\n| Automations ownership, routing, migration, persistence, and run lifecycle | `src\u002Fvs\u002Fsessions\u002FAUTOMATIONS.md` |\n| Workbench parts, grid, title bar, editor presentation | `src\u002Fvs\u002Fsessions\u002FLAYOUT.md` |\n| Session-aware layout state and restoration | `src\u002Fvs\u002Fsessions\u002FLAYOUT_CONTROLLER.md` |\n| Desktop layout scenarios and expected compositions | `src\u002Fvs\u002Fsessions\u002FDESKTOP.md` |\n| Sessions sidebar list, grouping, filtering, and persistence | `src\u002Fvs\u002Fsessions\u002FSESSIONS_LIST.md` |\n| Phone layout and mobile components | `src\u002Fvs\u002Fsessions\u002FMOBILE.md` |\n| AI customizations | `src\u002Fvs\u002Fsessions\u002FAI_CUSTOMIZATIONS.md` |\n| Copilot customizations | `src\u002Fvs\u002Fsessions\u002Fcopilot-customizations-spec.md` |\n| Copilot Chat provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FcopilotChatSessions\u002FCOPILOT_CHAT_SESSIONS_PROVIDER.md` |\n| Agent Host provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FagentHost\u002FAGENT_HOST_SESSIONS_PROVIDER.md` |\n| Remote Agent Host provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FremoteAgentHost\u002FREMOTE_AGENT_HOST_SESSIONS_PROVIDER.md` |\n\nDo not load the learning inbox by default. Search its headings and scopes, then read only matching entries after the authoritative specification.\n\n## 3. Inspect before changing\n\n- Trace the current implementation and its existing tests.\n- Search for shared helpers, context keys, menu IDs, entry-point imports, and provider abstractions before adding new ones.\n- Confirm which layer owns the behavior. Keep provider-specific decisions in the provider and view\u002Flayout decisions in Sessions-owned browser code.\n- For UI work, also invoke the applicable accessibility, design, CSS, layout, or theming skill.\n- For agent, LLM, policy, permissions, telemetry, or managed-setting changes, invoke the applicable specialist skill before implementation.\n\n## 4. Implement the contract\n\nApply the core principles and the focused specification. Prefer small changes that preserve these boundaries:\n\n- `ISessionsManagementService` owns model orchestration and provider routing.\n- `ISessionsService` owns visible and active session behavior.\n- Providers expose provider-neutral state through `ISession` and `IChat`.\n- Session state is observable; consumers derive UI state reactively.\n- Contributions load through the appropriate `sessions.*.main.ts` entry point.\n- Sessions menus use the shared `Menus` registry.\n- Shared workbench changes represent shared capability, not Sessions-specific policy.\n\n### Specification edit gate\n\nBug fixes do not update specifications when they restore an existing contract. Before editing an authoritative specification, identify all three:\n\n1. the existing ownership, interface, lifecycle, state-machine, persistence, or cross-component contract that intentionally changes;\n2. the implementation surfaces affected by that contract change;\n3. why a regression test and a brief code comment cannot fully represent it.\n\nIf any answer is missing, leave the specification unchanged. Put concrete behavior in a focused test, keep a non-obvious implementation constraint beside the owning code, and preserve investigation history in the issue or pull request.\n\nUpdate a specification only when component ownership, an interface or lifecycle contract, a state machine, persistence, or a cross-component invariant changes. Do not update specifications for styling, copy, action placement, telemetry fields, settings defaults, implementation algorithms, or individual bug fixes. Those details belong in code and focused tests.\n\n## 5. Validate proportionally\n\nRun the smallest existing checks that cover the change:\n\n- focused unit tests for affected behavior;\n- `pnpm run valid-layers-check` when imports or module ownership change;\n- targeted type checking or compilation when TypeScript changes warrant it;\n- relevant integration, E2E, or visual validation for cross-process or UI work.\n\nDocumentation-only changes require link, path, and consistency checks rather than a full build.\n\n## 6. Record feedback correctly\n\nWhen a user explicitly corrects or rejects an approach, invoke the `feedback-learning` skill unless they use the literal `learn!` trigger. Literal `learn!` requests follow `.github\u002Finstructions\u002Flearnings.instructions.md` instead. A durable architecture invariant belongs in the owning specification, concrete behavior belongs in a regression test, and unproven reusable guidance belongs temporarily in the scoped learning inbox. Never append every correction to this skill.\n\n## 7. Maintain this skill\n\nUpdate this skill only when a principle is stable, cross-cutting, and useful for most Agents Window work, or when the routing\u002Fworkflow itself changes. Put subsystem contracts in their focused specification and bug behavior in tests.\n\nKeep the core-principles section at no more than ten bullets. Before adding one, merge overlap, remove obsolete guidance, and prefer rewriting an existing principle. Never append incident-specific details or use this skill as a learning log.\n","# Agents Window development\n\nUse this skill for implementation, review, or design work under `src\u002Fvs\u002Fsessions\u002F**`.\n\n## 1. Apply the core principles\n\n- Preserve the layer direction: `vs\u002Fsessions` may import `vs\u002Fworkbench` and lower layers; `vs\u002Fworkbench` must never import `vs\u002Fsessions`.\n- Keep shared Sessions code provider-neutral. Non-provider contributions must not import provider implementations.\n- Model mutable session and chat state with observables. Use events for notifications, not as a parallel state model or for control flow.\n- Register Sessions menu IDs in `browser\u002Fmenus.ts` and consume `Menus.*`.\n- Import contributions from the appropriate `sessions.*.main.ts` entry point.\n- Prefer Sessions-owned adaptations over shared workbench changes unless the capability is genuinely shared.\n- Put stable architecture in the owning specification and concrete behavior in tests. Do not preserve implementation chronology as development guidance.\n\n## 2. Identify the owning area\n\nStart with `src\u002Fvs\u002Fsessions\u002FREADME.md`, then read only the specifications relevant to the change:\n\n| Area | Specification |\n|------|---------------|\n| Layering, folder ownership, cross-module imports | `src\u002Fvs\u002Fsessions\u002FLAYERS.md` |\n| Session\u002Fchat model, services, provider contract, core data flow | `src\u002Fvs\u002Fsessions\u002FSESSIONS.md` |\n| Automations ownership, routing, migration, persistence, and run lifecycle | `src\u002Fvs\u002Fsessions\u002FAUTOMATIONS.md` |\n| Workbench parts, grid, title bar, editor presentation | `src\u002Fvs\u002Fsessions\u002FLAYOUT.md` |\n| Session-aware layout state and restoration | `src\u002Fvs\u002Fsessions\u002FLAYOUT_CONTROLLER.md` |\n| Desktop layout scenarios and expected compositions | `src\u002Fvs\u002Fsessions\u002FDESKTOP.md` |\n| Sessions sidebar list, grouping, filtering, and persistence | `src\u002Fvs\u002Fsessions\u002FSESSIONS_LIST.md` |\n| Phone layout and mobile components | `src\u002Fvs\u002Fsessions\u002FMOBILE.md` |\n| AI customizations | `src\u002Fvs\u002Fsessions\u002FAI_CUSTOMIZATIONS.md` |\n| Copilot customizations | `src\u002Fvs\u002Fsessions\u002Fcopilot-customizations-spec.md` |\n| Copilot Chat provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FcopilotChatSessions\u002FCOPILOT_CHAT_SESSIONS_PROVIDER.md` |\n| Agent Host provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FagentHost\u002FAGENT_HOST_SESSIONS_PROVIDER.md` |\n| Remote Agent Host provider | `src\u002Fvs\u002Fworkbench\u002Fcontrib\u002Fsessions\u002Fproviders\u002FremoteAgentHost\u002FREMOTE_AGENT_HOST_SESSIONS_PROVIDER.md` |\n\nDo not load the learning inbox by default. Search its headings and scopes, then read only matching entries after the authoritative specification.\n\n## 3. Inspect before changing\n\n- Trace the current implementation and its existing tests.\n- Search for shared helpers, context keys, menu IDs, entry-point imports, and provider abstractions before adding new ones.\n- Confirm which layer owns the behavior. Keep provider-specific decisions in the provider and view\u002Flayout decisions in Sessions-owned browser code.\n- For UI work, also invoke the applicable accessibility, design, CSS, layout, or theming skill.\n- For agent, LLM, policy, permissions, telemetry, or managed-setting changes, invoke the applicable specialist skill before implementation.\n\n## 4. Implement the contract\n\nApply the core principles and the focused specification. Prefer small changes that preserve these boundaries:\n\n- `ISessionsManagementService` owns model orchestration and provider routing.\n- `ISessionsService` owns visible and active session behavior.\n- Providers expose provider-neutral state through `ISession` and `IChat`.\n- Session state is observable; consumers derive UI state reactively.\n- Contributions load through the appropriate `sessions.*.main.ts` entry point.\n- Sessions menus use the shared `Menus` registry.\n- Shared workbench changes represent shared capability, not Sessions-specific policy.\n\n### Specification edit gate\n\nBug fixes do not update specifications when they restore an existing contract. Before editing an authoritative specification, identify all three:\n\n1. the existing ownership, interface, lifecycle, state-machine, persistence, or cross-component contract that intentionally changes;\n2. the implementation surfaces affected by that contract change;\n3. why a regression test and a brief code comment cannot fully represent it.\n\nIf any answer is missing, leave the specification unchanged. Put concrete behavior in a focused test, keep a non-obvious implementation constraint beside the owning code, and preserve investigation history in the issue or pull request.\n\nUpdate a specification only when component ownership, an interface or lifecycle contract, a state machine, persistence, or a cross-component invariant changes. Do not update specifications for styling, copy, action placement, telemetry fields, settings defaults, implementation algorithms, or individual bug fixes. Those details belong in code and focused tests.\n\n## 5. Validate proportionally\n\nRun the smallest existing checks that cover the change:\n\n- focused unit tests for affected behavior;\n- `pnpm run valid-layers-check` when imports or module ownership change;\n- targeted type checking or compilation when TypeScript changes warrant it;\n- relevant integration, E2E, or visual validation for cross-process or UI work.\n\nDocumentation-only changes require link, path, and consistency checks rather than a full build.\n\n## 6. Record feedback correctly\n\nWhen a user explicitly corrects or rejects an approach, invoke the `feedback-learning` skill unless they use the literal `learn!` trigger. Literal `learn!` requests follow `.github\u002Finstructions\u002Flearnings.instructions.md` instead. A durable architecture invariant belongs in the owning specification, concrete behavior belongs in a regression test, and unproven reusable guidance belongs temporarily in the scoped learning inbox. Never append every correction to this skill.\n\n## 7. Maintain this skill\n\nUpdate this skill only when a principle is stable, cross-cutting, and useful for most Agents Window work, or when the routing\u002Fworkflow itself changes. Put subsystem contracts in their focused specification and bug behavior in tests.\n\nKeep the core-principles section at no more than ten bullets. Before adding one, merge overlap, remove obsolete guidance, and prefer rewriting an existing principle. Never append incident-specific details or use this skill as a learning log.\n",{"name":5,"description":7},"main","b4bd9bd3c0171f72f54d742b8152db735fd9ce0a",".github\u002Fskills\u002Fsessions",43828,"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-14 03:06:00",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add microsoft\u002Fvscode --skill sessions",{"tool":50,"command":51},"bunx","bunx skills add microsoft\u002Fvscode --skill sessions",{"tool":53,"command":54},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill sessions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsessions\u002FSKILL.md",true,[],[59,86,107,120,135,151],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":29},"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",[],[66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85],"sweeper query","query","sweeper","review","fix","when","request","which","natural-language","ranking","duplicates","ready","only","read","plan","open","Citations","brief","issues","code",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":29},"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",[],[93,94,26,95,96,97,98,99,100,101,102,103,104,105,106,5,71],"update","update skills","pattern","domain","learnings","reusable","use","session","user","instructions","knowledge","repository","learn","create",{"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":113,"publishedAt":29},"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",[],[93,114,115,71,72,116,26,99,100,101,117,118,119,27],"pr","update pr","Existing","push","pull","pull request",{"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":29},"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,117,118,129,71,27,130,131,132,133,99,100,101,134],"SET","publish","rebase","latest","with","remote","upstream","branch",{"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":29},"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",[],[133,122,142,143,71,144,145,27,130,146,147,148,149,99,100,134,150,93],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":29},"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",[],[153,100,99,150,134,101,71,158,159,27],"back","base"]