@codingame/monaco-vscode-chat-service-override 37.3.7 → 37.3.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codingame/monaco-vscode-chat-service-override",
-  "version": "37.3.7",
+  "version": "37.3.9",
   "private": false,
   "description": "VSCode public API plugged on the monaco editor - chat service-override",
   "keywords": [],
@@ -15,9 +15,10 @@
   },
   "type": "module",
   "dependencies": {
-    "@codingame/monaco-vscode-api": "37.3.7",
-    "@codingame/monaco-vscode-katex-common": "37.3.7",
-    "@codingame/monaco-vscode-xterm-common": "37.3.7"
+    "@codingame/monaco-vscode-api": "37.3.9",
+    "@codingame/monaco-vscode-files-service-override": "37.3.9",
+    "@codingame/monaco-vscode-katex-common": "37.3.9",
+    "@codingame/monaco-vscode-xterm-common": "37.3.9"
   },
   "main": "index.js",
   "module": "index.js",

package/session.js

@@ -40,7 +40,17 @@ import './vscode/src/vs/sessions/contrib/providers/remoteAgentHost/browser/webSo
 import '@codingame/monaco-vscode-api/vscode/vs/sessions/contrib/providers/remoteAgentHost/browser/webTunnelAgentHostService.contribution';
 import './vscode/src/vs/sessions/contrib/providers/remoteAgentHost/browser/wslAgentHost.contribution.js';
 import './vscode/src/vs/sessions/contrib/providers/remoteAgentHost/browser/remoteAgentHost.contribution.js';
+import skillAssets from './vscode/src/vs/sessions/skills/all_/SKILL.md.js';
+import { FileAccess } from '@codingame/monaco-vscode-api/vscode/vs/base/common/network';
+import { RegisteredFileSystemProvider, RegisteredUriFile, registerCustomProvider } from '@codingame/monaco-vscode-files-service-override';
+import { URI } from '@codingame/monaco-vscode-api/vscode/vs/base/common/uri';
 
+FileAccess.registerAppResourcePathUrl('vs/sessions/skills', 'skills:/vs/sessions/skills');
+const skillFileSystemProvider = new RegisteredFileSystemProvider(true);
+for (const [assetPath, assetUrl] of Object.entries(skillAssets)) {
+    skillFileSystemProvider.registerFile(new RegisteredUriFile(URI.from({ scheme: 'skills', path: assetPath }), assetUrl));
+}
+registerCustomProvider('skills', skillFileSystemProvider);
 function getServiceOverride({ defaultAccount } = {}) {
     return {
         ...getServiceOverride$1({ defaultAccount }),

package/vscode/src/vs/sessions/skills/act-on-feedback/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: act-on-feedback
+description: Act on user feedback attached to the current session. Use when the user submits feedback on the session's changes via the Submit Feedback button.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Act on Feedback
+
+The user has provided feedback on the current session's changes.
+
+1. Use the `listComments` tool to retrieve the user's feedback comments for this session
+2. If specific feedback comments were attached to this message, act on **only** those attached comments (match them by their comment id); otherwise act on all of the listed comments, or whatever subset the user specified in their message
+3. Understand the intent behind each piece of feedback you are acting on
+4. Make the requested changes to address the feedback
+5. When feedback has been tackled, use the `resolveComments` tool to mark those comments as resolved, or the `deleteComments` tool to delete them
+6. Verify your changes are consistent with the rest of the codebase

package/vscode/src/vs/sessions/skills/all_/SKILL.md.js

@@ -0,0 +1,17 @@
+var skillAssets = {
+  'vs/sessions/skills/act-on-feedback/SKILL.md': new URL('../act-on-feedback/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/code-review/SKILL.md': new URL('../code-review/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/commit/SKILL.md': new URL('../commit/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/create-draft-pr/SKILL.md': new URL('../create-draft-pr/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/create-pr/SKILL.md': new URL('../create-pr/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/fix-ci/SKILL.md': new URL('../fix-ci/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/generate-run-commands/SKILL.md': new URL('../generate-run-commands/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/merge/SKILL.md': new URL('../merge/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/sync-upstream/SKILL.md': new URL('../sync-upstream/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/troubleshoot/SKILL.md': new URL('../troubleshoot/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/sync/SKILL.md': new URL('../sync/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/update-pr/SKILL.md': new URL('../update-pr/SKILL.md', import.meta.url).href,
+  'vs/sessions/skills/update-skills/SKILL.md': new URL('../update-skills/SKILL.md', import.meta.url).href
+};
+
+export { skillAssets as default };

package/vscode/src/vs/sessions/skills/code-review/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: code-review
+description: Perform a code review of the current session's changes. Use when the user requests a code review via the Run Code Review button in the Changes toolbar.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Code Review
+
+You are a coding agent acting as a code reviewer. Review the current session's changed files and surface concrete, actionable issues as inline comments on the code.
+
+## Workflow
+
+1. Determine the set of changed files in the current session (e.g. `git status`, `git diff`).
+2. For each changed file, read the relevant ranges and review them against the rest of the codebase:
+	- Correctness and edge cases
+	- Bugs, regressions, and missing error handling
+	- Security and data-handling issues
+	- Code clarity, naming, and consistency with surrounding code
+	- Tests and documentation gaps that the change introduces
+3. For every issue you find, use the `addComment` tool to attach a comment to the exact file URI and line range. Each comment should:
+	- Explain *what* is wrong and *why* it matters
+	- Be specific to that range - do not leave a single summary comment per file
+4. Prefer fewer, higher-signal comments over many minor stylistic nits. Do not comment on things that are already correct.
+5. Do not modify files. Do not run commits, pushes, or other write operations. Your only output is review comments.
+6. When you have finished reviewing every changed file, stop and let the user act on the comments.

package/vscode/src/vs/sessions/skills/commit/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: commit
+description: Commit staged or unstaged changes with an AI-generated commit message that matches the repository's existing commit style. Use when the user asks to 'commit', 'commit changes', 'create a commit', 'save my work', or 'check in code'.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Commit Changes
+
+Help the user commit code changes with a well-crafted commit message derived from the diff, following the conventions already established in the repository.
+
+## Guidelines
+
+- **Never amend existing commits** without asking.
+- **Never force-push or push** without explicit user approval.
+- **Never skip pre-commit hooks** (do not use `--no-verify`).
+- **Never skip signing commits** (do not use `--no-gpg-sign`).
+- **Never revert, reset, or discard user changes** unless the user explicitly asked for that.
+- Check for obvious secrets or generated artifacts that should not be committed. If something looks risky - ask the user.
+- When in doubt about staging, convention, or message content — ask the user.
+
+## Workflow
+
+### 1. Discover the repository's commit convention
+
+Run the following to sample recent commits and the user's own commits:
+
+```
+# Recent repo commits (for overall style)
+git log --oneline -20
+
+# User's recent commits (for personal style)
+git log --oneline --author="$(git config user.name)" -10
+```
+
+Analyse the output to determine the commit message convention used in the repository (e.g. Conventional Commits, Gitmoji, ticket-prefixed, free-form). All generated messages **must** follow the detected convention.
+
+### 2. Check repository status
+
+```
+git status --short
+```
+
+- If there are **no changes** (working tree clean, nothing staged), inform the user and stop.
+- If there are **staged changes**, proceed with those and do not stage any unstaged changes.
+- If there are **only unstaged changes**, stage everything (`git add -A`), and proceed with those.
+
+### 3. Generate the commit message
+
+Obtain the full diff of what will be committed:
+
+```bash
+git diff --cached --stat
+git diff --cached
+```
+
+Using the diff and the commit convention detected in step 1, draft a commit message with:
+
+- A **subject line** (≤ 72 characters) that summarises the change, following the repository's convention.
+- An optional **body** that explains *why* the change was made, only when the diff is non-trivial.
+- Reference issue/ticket numbers when they appear in branch names or related context.
+- Focus on the intent of the change, not a file-by-file inventory.
+
+### 4. Commit
+
+Construct the `git commit` command with the generated message.
+
+Execute the commit:
+
+```
+git commit -m "<subject>" -m "<body>"
+```
+
+### 5. Confirm
+
+After the commit:
+
+- Run `git status --short` to confirm the commit completed.
+- Run `git log --oneline -1` to show the new commit.
+- If pre-commit hooks changed files or blocked the commit, summarize exactly what happened.
+- If hooks rewrote files after the commit attempt, do not amend automatically. Tell the user what changed and ask whether they want you to stage and commit those follow-up edits.

package/vscode/src/vs/sessions/skills/create-draft-pr/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: create-draft-pr
+description: Create a draft pull request for the current session. Use when the user wants to open a draft PR with the session's changes.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Create Draft Pull Request
+
+Use the GitHub MCP server to create a draft pull request if available, otherwise use `gh` CLI.
+
+1. Run the compile and hygiene tasks (fixing any errors)
+2. If there are any uncommitted changes, use the `/commit` skill to commit them
+3. Review all changes in the current session
+4. Write a clear, concise PR title with a short area prefix (e.g. "sessions: …", "editor: …")
+5. Write a description covering what changed, why, and anything reviewers should know
+6. Create the draft pull request

package/vscode/src/vs/sessions/skills/create-pr/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: create-pr
+description: Create a pull request for the current session. Use when the user wants to open a PR with the session's changes.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Create Pull Request
+
+Use the GitHub MCP server to create a pull request if available, otherwise use `gh` CLI.
+
+1. Run the compile and hygiene tasks (fixing any errors)
+2. If there are any uncommitted changes, use the `/commit` skill to commit them
+3. Review all changes in the current session
+4. Write a clear, concise PR title with a short area prefix (e.g. "sessions: …", "editor: …")
+5. Write a description covering what changed, why, and anything reviewers should know
+6. Create the pull request, passing `show_ui=false` so the PR is created without opening a confirmation UI

package/vscode/src/vs/sessions/skills/fix-ci/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: fix-ci
+description: Fix the failed CI checks for the current session. Use when the user requests a CI fix via the Fix Checks button in the Changes toolbar.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Fix CI
+
+Please fix the failed CI checks for this session immediately.
+
+Use the failed check information provided with this message, including annotations and check output, to identify the root causes and make the necessary code changes.
+
+## Workflow
+
+1. Read the failed check information attached to this message. It includes a link to the pull request, and for each failed check the check name, status, conclusion, a details URL, and any annotations or output.
+2. Use the annotations and output to identify the root cause of each failure (e.g. compile errors, lint/hygiene violations, failing tests).
+3. Make the necessary code changes to resolve the failures. Focus on resolving these CI failures and avoid unrelated changes unless they are required to fix the checks.
+4. Validate your changes locally where possible (e.g. compile, lint, run the relevant tests) to confirm the failures are addressed.

package/vscode/src/vs/sessions/skills/generate-run-commands/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: generate-run-commands
+description: Generate or modify run commands for the current session. Use when the user wants to set up or update run commands that appear in the session's Run button.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Generate Run Commands
+
+Help the user set up run commands for the current Agent Session workspace. Run commands appear in the session's Run button in the title bar.
+
+## Understanding the task schema
+
+A run command is a `tasks.json` task with:
+- `"inAgents": true` — required: makes the task appear in the Agents run button
+- `"runOptions": { "runOn": "worktreeCreated" }` — optional: auto-runs the task whenever a new worktree is created (use for setup/install commands)
+
+```json
+{
+  "tasks": [
+    {
+      "label": "Install dependencies",
+      "type": "shell",
+      "command": "npm install",
+      "inAgents": true,
+      "runOptions": { "runOn": "worktreeCreated" }
+    },
+    {
+      "label": "Start dev server",
+      "type": "shell",
+      "command": "npm run dev",
+      "inAgents": true
+    }
+  ]
+}
+```
+
+## Decision logic
+
+**First, read the existing `.vscode/tasks.json`** to check for existing run commands (`inAgents: true` tasks).
+
+**If run commands already exist:** treat this as a modify request — ask the user what they'd like to change (add, remove, or update a command).
+
+**If no run commands exist:** try to infer the right commands from the workspace:
+- Check `package.json`, `Makefile`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `.nvmrc`, or other project files to understand the stack and common commands.
+- If it's clear what the setup command is (e.g., `npm install`, `pip install -r requirements.txt`), add it with `"runOptions": { "runOn": "worktreeCreated" }` — no need to ask.
+- If it's clear what the primary run/dev command is (e.g., `npm run dev`, `cargo run`), add it with just `"inAgents": true`.
+- **Only ask the user** if the commands are ambiguous (e.g., multiple equally valid options, no recognizable project structure, or the project uses a non-standard setup).
+
+## Writing the file
+
+Always write to `.vscode/tasks.json` in the workspace root. If the file already exists, merge — do not overwrite unrelated tasks.
+
+After writing, briefly confirm what was added and how to trigger it from the Run button.

package/vscode/src/vs/sessions/skills/merge/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: merge
+description: 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.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Merge Changes
+
+Merge the topic branch (checked out in the current worktree) into the merge base branch (checked out in the main worktree). The context block appended to the prompt contains the source branch, target branch, and main worktree path.
+
+## Guidelines
+
+- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
+- **Never skip pre-push hooks** (do not use `--no-verify`).
+- **Never rewrite or drop commits** without asking the user.
+- When in doubt about conflict resolution — ask the user.
+
+## Workflow
+
+### 1. Commit uncommitted changes in the current worktree
+
+Check for uncommitted changes in the current worktree:
+```
+git status --porcelain
+```
+If there are uncommitted changes, use the `/commit` skill to commit them before continuing.
+
+### 2. Merge the topic branch into the base branch
+
+Use `git -C <main-worktree-path>` to run commands against the main worktree without leaving the current worktree.
+
+```
+git -C <main-worktree-path> merge <topic-branch>
+```
+
+### 3. Handle merge conflicts
+
+If the merge reports conflicts:
+
+3.1. List conflicted files:
+```
+git -C <main-worktree-path> diff --name-only --diff-filter=U
+```
+
+3.2. For each conflicted file, read the file content, resolve the conflict by preserving the intent of both sides, and stage the resolved file:
+```
+git -C <main-worktree-path> add <resolved-file>
+```
+
+3.3. When in doubt on how to resolve a merge conflict, ask the user for guidance. If the user wants to abort, run:
+```
+git -C <main-worktree-path> merge --abort
+```
+
+3.4. Once all conflicts are resolved and staged, commit the merge:
+```
+git -C <main-worktree-path> commit --no-edit
+```
+
+## Validation
+
+After the merge completes, verify the result:
+
+1. Confirm the main worktree is clean:
+```
+git -C <main-worktree-path> status --porcelain
+```
+
+2. Confirm the topic branch is an ancestor of the base branch (i.e. all commits are merged):
+```
+git -C <main-worktree-path> merge-base --is-ancestor <topic-branch> HEAD
+```

package/vscode/src/vs/sessions/skills/sync/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: sync
+description: 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.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Sync Changes
+
+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.
+
+## Guidelines
+
+- **Never force-push** (`--force`, `--force-with-lease`) without explicit user approval.
+- **Never skip pre-push hooks** (do not use `--no-verify`).
+- **Never rewrite or drop commits** during rebase without asking the user.
+- When in doubt about conflict resolution — ask the user.
+
+## Workflow
+
+1. Check for uncommitted changes first. If there are uncommitted changes, use the `/commit` skill to commit them before continuing.
+2. Check whether the current session branch has an upstream branch.
+3. If the current session branch has an upstream branch:
+   3.1. Fetch the upstream remote first so tracking refs are up to date.
+      ```
+      git fetch <upstream-remote>
+      ```
+   3.2. Check ahead/behind counts. If the branch is already in sync (0 ahead, 0 behind), stop and report that no sync is needed.
+      ```
+      git rev-list --left-right --count HEAD...@{u}
+      ```
+   3.3. If behind, rebase onto the upstream tracking branch.
+      ```
+      git rebase @{u}
+      ```
+   3.4. If there are merge conflicts, resolve them by preserving the intent of both sides. Stage the resolved files and continue the rebase.
+      ```
+      git add <resolved-files>
+      git rebase --continue
+      ```
+      If conflict resolution is unclear, ask the user how to proceed. If the user wants to stop the rebase, abort it:
+      ```
+      git rebase --abort
+      ```
+   3.5. If the branch has local commits (ahead > 0), push them to the remote after a successful rebase.
+      ```
+      git push
+      ```
+      If the push is rejected because the rebase rewrote history, explain the situation to the user and ask for approval before force-pushing.
+4. If the current session branch does not have an upstream branch:
+   4.1. Determine the remote to publish to.
+      - If there is only one remote, use it.
+      - If there are multiple remotes, use the #tool:vscode/askQuestions tool to ask which remote to use.
+   4.2. Publish the current branch and set upstream in one step.
+      ```
+      git push -u <remote> HEAD
+      ```
+
+## Validation
+
+After the workflow completes, validate the result with explicit checks:
+
+1. Verify the working tree is clean:
+   ```
+   git status --porcelain
+   ```
+2. Verify sync state (ahead/behind counts are both 0):
+   ```
+   git rev-list --left-right --count HEAD...@{u}
+   ```
+3. If the branch was newly published, verify the upstream branch is configured:
+   ```
+   git rev-parse --abbrev-ref --symbolic-full-name @{u}
+   ```

package/vscode/src/vs/sessions/skills/sync-upstream/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: sync-upstream
+description: 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.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Update Branch
+
+Rebase the current session branch onto the latest upstream so the work stays grounded in origin.
+
+## Workflow
+
+1. If there are uncommitted changes, use the `/commit` skill to commit them first.
+2. Fetch the latest upstream and rebase onto it:
+   ```
+   git fetch origin
+   git rebase origin/main
+   ```
+   Use the appropriate base branch if it is not `main`.
+
+## Conflict Resolution
+
+When conflicts arise, **upstream always wins**:
+
+- **Never alter upstream logic, APIs, or patterns** to accommodate session changes.
+- **Adapt session work** to fit the new upstream — rename, restructure, or rewrite as needed while preserving the session's goals.
+- After resolving each conflict, `git add` the files and `git rebase --continue`.
+
+## Validation
+
+After the rebase completes, verify the result still compiles and meets the session's objectives. If session changes no longer make sense against the updated upstream, explain what changed and propose a revised approach.

package/vscode/src/vs/sessions/skills/troubleshoot/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: troubleshoot
+description: Investigate unexpected behavior in the current Copilot agent session by analyzing its event log. Use when the user asks why something happened, why a request was slow, why a tool was or was not used, or why instructions/skills/agents did not load.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Troubleshoot
+
+## Purpose
+
+This skill investigates and explains unexpected agent behavior in the **current Copilot agent session** using its on-disk event log.
+
+Use this skill for questions like:
+- Why did this request take so long?
+- Why was a tool called (or not called)?
+- Why did an instruction/skill/agent file not load?
+- Why did a tool call fail?
+- Why did the model not follow expectations?
+
+Base every conclusion on evidence from the event log. Do not guess.
+
+## Locating the Session Log
+
+The skill runs **inside** the session's agent, so the log is on the same machine. It lives outside the workspace — read it via the terminal (`run_in_terminal`), never `grep_search`.
+
+1. **If a `Session log:` path is provided with this message, use it.** It may point to a session **other than** the current one (via `#session`) and may be **comma-separated paths** — investigate all of them and compare.
+2. **Sticky reference:** if no path is on the *current* message but an earlier turn in **this conversation** already established a target (a `Session log:` path, or a `#session:` reference), keep analyzing **that same session** for the follow-up. Do **not** fall back to self-discovery here — the newest log is the *current* session, which is the wrong one. Switch only if the user references a new session.
+3. **Otherwise, self-discover it:** pick the **most recently modified** `events.jsonl` under `${XDG_STATE_HOME:-$HOME}/.copilot/session-state/<sessionId>/` — this skill is appending to the current session's log, so it's reliably newest. Honor `XDG_STATE_HOME`, else `$HOME`.
+4. **If none exists** there, this isn't a Copilot session — tell the user the skill supports Copilot sessions only, and stop.
+
+## Data Source — `events.jsonl`
+
+Each line is a JSON object sharing one envelope:
+
+```json
+{ "type": "...", "id": "...", "parentId": "...", "agentId": "...", "timestamp": "ISO-8601", "data": { } }
+```
+
+- `type` — the event kind (see below).
+- `id` — unique event id.
+- `parentId` — the **chronologically preceding** event, not a logical parent. It is a flat back-pointer over every event, *not* the user → turn → tool-call hierarchy. Do not treat it as a logical parent.
+- `agentId` — present for sub-agent events; absent for the main agent and session-level events.
+- `timestamp` — ISO-8601 time. Compute durations by differencing timestamps (e.g. a tool's start vs. its completion, a turn's `assistant.turn_start` vs. the `assistant.message`).
+- `data` — type-specific payload.
+
+### Event types (`data.*` fields)
+
+- **`session.start`** (once) — `selectedModel`, `reasoningEffort`.
+- **`user.message`** — `content`; `transformedContent` (expanded prompt, when it differs).
+- **`assistant.turn_start` / `assistant.turn_end`** — `turnId`; measure a turn's duration vs the following `assistant.message`.
+- **`assistant.message`** — `model`, `outputTokens`, `content`, `reasoningText` (thinking, when present), `turnId`, `parentToolCallId` (set ⇒ sub-agent turn spawned by that tool call).
+- **`tool.execution_start`** — `toolName`, `toolCallId`, `arguments`, `parentToolCallId` (set ⇒ nested/sub-agent).
+- **`tool.execution_complete`** — `toolCallId` (matches start), `success`, `result`. Pair with its start by `toolCallId` for the full call + duration.
+- **`session.shutdown`** (once, at end) — `modelMetrics[*].usage`, `totalNanoAiu`. Absent mid-session.
+- Other (`hook.*`, `permission.*`, `system.message`) — inspect `data` as needed.
+
+### Reconstructing the flow
+
+Iterate records in order and rebuild the logical tree from context:
+- `session.start` is the root.
+- a `user.message` begins a turn.
+- an `assistant.message` answers the current `user.message` — unless it has `data.parentToolCallId`, in which case it belongs to the sub-agent spawned by that tool call.
+- a `tool.execution_start` belongs to the current `assistant.message` — unless it has `data.parentToolCallId`, in which case it is nested under that parent tool call.
+- pair each `tool.execution_start` with its `tool.execution_complete` by `toolCallId`.
+
+## Secondary Source — Agent Host Wire Log (protocol communication)
+
+`events.jsonl` is the **primary** source and answers almost every question on its own. A *separate* log captures the **transport/protocol** between VS Code and the agent host process — the JSON-RPC-style frames that drive sessions.
+
+**Use the wire log only when the symptom points at the agent host / transport itself, not the model or a tool.** Reach for it when:
+- the agent host won't start, or the session never begins;
+- requests **hang or time out**, or the agent appears stuck "connecting" / unresponsive;
+- `createSession` / `subscribe` fails, or expected updates/notifications never arrive;
+- you see RPC / protocol / connection errors.
+
+**Do not** open it for ordinary "why did the model/tool do X" questions — `events.jsonl` already answers those. If `events.jsonl` fully explains the behavior, stop there and don't read the wire log.
+
+**It is written by VS Code on the _client_ machine, so it is only reachable for a _local_ agent host** (VS Code and the agent on the same machine). For a remote agent host it lives on the client, not the host this skill runs on — skip it there.
+
+### Location
+
+```
+<VS Code user-data dir>/logs/<session-timestamp>/ahp/ahp-<timestamp>-<connectionId>.jsonl
+```
+
+The VS Code user-data dir depends on the build:
+- Windows: `%APPDATA%\Code` (Insiders: `Code - Insiders`; OSS/dev may use `Code - OSS` or a custom `--user-data-dir`)
+- macOS: `~/Library/Application Support/Code`
+- Linux: `~/.config/Code`
+
+A new `logs/<timestamp>/` folder is created per VS Code session — pick the **most recently modified** `ahp/ahp-*.jsonl`.
+
+**Named by _connection_ id, not session id** — one log **multiplexes all sessions on that connection** (no per-session file). Long connections rotate into `ahp-….1.jsonl`, `.2.jsonl`, … (max 5); the active one is the **most recently modified** (the locate commands pick it). Read the newest log for connection-level health; to isolate one session, filter by its id (the `session-state/<sessionId>/` folder name, which appears in frames' `params`/`result`).
+
+**If no `ahp/` folder exists, the wire log is disabled** (it is off by default). Tell the user to set `"chat.agentHost.ahpJsonlLoggingEnabled": true`, restart VS Code, reproduce the issue, then re-run.
+
+### Format
+
+Each line is a JSON-RPC frame plus an `_ahpLog` envelope:
+
+```json
+{ "jsonrpc": "2.0", "id": 12, "method": "createSession", "params": {}, "_ahpLog": { "ts": "ISO-8601", "dir": "c2s", "connectionId": "…", "transport": "local" } }
+```
+
+- `_ahpLog.dir` — direction: `c2s` = VS Code → host (requests/notifications), `s2c` = host → VS Code (results/errors/actions/notifications).
+- `_ahpLog.transport` — `local` / `websocket` / `ssh` / `wsl`.
+- Requests/notifications carry `method` + `params`; responses carry `result` or `error` — pair a response to its request by `id`.
+- `_ahpLog.truncated: true` marks frames whose large payloads were elided.
+
+Triage: look for `error` frames, requests (`c2s` with an `id`) that have **no matching `s2c` response** (hangs/timeouts), or a missing `s2c` after `createSession` / `subscribe`. Apply the same streaming / `jq` / `node` rules as for `events.jsonl`.
+
+### Locating it (terminal)
+- macOS/Linux: `ls -t ~/Library/Application\ Support/Code*/logs/*/ahp/ahp-*.jsonl ~/.config/Code*/logs/*/ahp/ahp-*.jsonl 2>/dev/null | head -n 1`
+- Windows (PowerShell): `Get-ChildItem "$env:APPDATA\Code*\logs\*\ahp\ahp-*.jsonl" -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 1`
+
+## Tooling Strategy (important)
+
+The event log is outside the workspace, so `grep_search` cannot read it. **Use `run_in_terminal`.**
+
+### Do a single triage pass first (important for efficiency)
+
+Each terminal command is a separate round-trip, so **don't run one command per question.** Do **one streaming pass** (constant memory — `events.jsonl` can be hundreds of MB, so never load it whole) that prints, in a single read:
+- the event counts by type,
+- every tool call with success/failure and duration (pair each `tool.execution_start` with its `tool.execution_complete` by `toolCallId`),
+- the user messages.
+
+Use a streaming `jq` program (macOS/Linux) or a streaming Node `readline` pass (Windows) — the per-query examples below are the building blocks. Then run targeted follow-ups only to drill in.
+
+### macOS / Linux / WSL / Git Bash (`grep` / `jq`)
+- Locate the newest log: `ls -t "${XDG_STATE_HOME:-$HOME}"/.copilot/session-state/*/events.jsonl | head -n 1`
+- Check size first: `ls -lh <logPath>`
+- Errors: `grep '"success":false' <logPath>` (tool failures) and `grep '"type":"tool.execution_complete"' <logPath>`
+- Count events by type (streaming): `jq -nr 'reduce inputs as $i ({}; .[$i.type] += 1) | to_entries | sort_by(-.value)[] | "\(.value) \(.key)"' <logPath>`
+- Tool calls: `jq -c 'select(.type=="tool.execution_start") | {tool:.data.toolName, id:.data.toolCallId}' <logPath>`
+- User messages: `jq -c 'select(.type=="user.message") | .data.content' <logPath>`
+- Assistant turns: `jq -c 'select(.type=="assistant.message") | {model:.data.model, out:.data.outputTokens}' <logPath>`
+
+### Windows (PowerShell + Node.js)
+**Do not parse the log with PowerShell JSON.** `Get-Content … | ForEach-Object { ConvertFrom-Json }` (or any per-line `ConvertFrom-Json`) deserializes one object at a time and is slow even on small logs. Use `Select-String` for plain-text matches and a **streaming** `node` pass for anything that needs JSON. Use `jq` instead if it is available.
+
+- Locate the newest log:
+  ```powershell
+  $stateHome = if ($env:XDG_STATE_HOME) { $env:XDG_STATE_HOME } else { $HOME }
+  Get-ChildItem (Join-Path $stateHome '.copilot\session-state\*\events.jsonl') | Sort-Object LastWriteTime -Descending | Select-Object -First 1
+  ```
+- Check size first: `(Get-Item <logPath>).Length`
+- Plain-text matches (fast, streaming, no parsing): `Select-String '"success":false' <logPath>`
+- JSON queries — a **streaming** `node` pass (constant memory, safe for hundreds-of-MB logs; pass the log path as an argument so it stays quote-safe). Use this shape and change only the per-line `if (…)` to select what you need (tool failures, tool calls, assistant turns, …):
+    `node -e "const rl=require('readline').createInterface({input:require('fs').createReadStream(process.argv[1])});rl.on('line',l=>{if(!l)return;let x;try{x=JSON.parse(l)}catch{return}if(x.type==='tool.execution_complete'&&x.data.success===false)console.log(x.data.toolCallId,JSON.stringify(x.data.result))})" "<logPath>"`
+  For aggregates (e.g. counts by type), accumulate into an object as you go and print it on `rl.on('close', …)`.
+- For a very large log, narrow with `Select-String` first to find the line, then read that small slice with `read_file`.
+
+### General rules
+- **One streaming pass, not many.** Each command is a round-trip; prefer the single triage pass, then targeted follow-ups. Never load a whole (hundreds-of-MB) log into memory (`readFileSync` / `Get-Content`) — stream (`jq` / the readline pass) or narrow with `grep` / `Select-String` first. Check size first if unsure (`ls -lh` / `(Get-Item).Length`).
+- **Never deserialize JSON line-by-line in the shell** (PowerShell `ConvertFrom-Json` in a loop) — slow. Use one `jq` filter or one `node` pass.
+- Use `read_file` only for small targeted ranges, never an entire log.
+
+## Investigation Workflow
+
+1. Locate `events.jsonl` and run the single triage pass.
+2. Match the symptom: **errors** → `success:false`; **latency** → gaps between `assistant.turn_start` and its `assistant.message`, or a tool's start↔complete; **tool / model / input** → the relevant event type; **agent-host / transport** failure (local) → also the Wire Log.
+3. Read only the relevant slices, then determine the most likely root cause (order contributing factors by impact) and give concrete next steps.
+
+## Response Guidelines
+
+Cover **what happened and why** (root cause), **key evidence** (paraphrased — quote only a telling detail like an error message, never raw dumps), and **how to fix it**. A short combined explanation is fine; add structure (headers, bullets, tables) only for complex, multi-factor issues. Keep paragraphs short.
+
+**Abstraction:** don't narrate your investigation or use internal terms (`events.jsonl`, `tool.execution_start`, `parentId`, "envelope"). Refer to "the session log" abstractly. Focus on what happened and why, not how you found it.
+
+**Example** — instead of "I read events.jsonl and saw a `tool.execution_complete` with `success:false`…", say:
+
+> The "testing" skill was found but not loaded because the folder name and the name in the skill file differ (`testing` vs `testing2`). **Fix:** make them match (rename the folder or change the name), then start a new session.
+
+## Important Rules
+
+- Base every claim on log evidence — never assume causality.
+- Search via `run_in_terminal`; never `grep_search`, and never `read_file` a whole (possibly huge) log — narrow first, then read small ranges.
+- If no Copilot session log exists, say so and stop.

package/vscode/src/vs/sessions/skills/update-pr/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: update-pr
+description: Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Update Pull Request
+
+Update the existing pull request for the current session.
+The context block appended to the prompt contains the pull request information.
+
+1. Check whether the pull request has any commits that are not yet present on the current branch (incoming changes). If there are any incoming changes, pull them into the current branch and resolve any merge conflicts
+2. Run the compile and hygiene tasks (fixing any errors)
+3. If there are any uncommitted changes, use the `/commit` skill to commit them
+4. If the outgoing changes introduce significant changes to the pull request, update the pull request title and description to reflect those changes
+5. Update the pull request with the new commits and information

package/vscode/src/vs/sessions/skills/update-skills/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: update-skills
+description: 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.
+---
+<!-- Customize this skill and select save to override its behavior. Delete that copy to restore the built-in behavior. -->
+
+# Update Skills & Instructions
+
+When a major repository learning is discovered — a recurring pattern, a non-obvious pitfall, a crucial architectural constraint, or domain knowledge that would save future sessions significant time — capture it as a skill or instruction so it persists across sessions.
+
+## When to Use
+
+- The user explicitly says **"learn!"** or asks to capture a learning
+- You discover a significant pattern or constraint that cost meaningful debugging time
+- You identify reusable domain knowledge that isn't documented anywhere in the repo
+- A correction from the user reveals a general principle worth preserving
+
+## Decision: Skill vs Instruction vs Learning
+
+**Add a learning to an existing instruction** when:
+- The insight is small (1-4 sentences) and fits naturally into an existing instruction file
+- It refines or extends an existing guideline
+- Follow the pattern in `.github/instructions/learnings.instructions.md`
+
+**Create or update a skill** (`.github/skills/{name}/SKILL.md` or `.agents/skills/{name}/SKILL.md`) when:
+- The knowledge is substantial (multi-step procedure, detailed guidelines, or rich examples)
+- It covers a distinct domain area (e.g., "how to debug X", "patterns for Y")
+- Future sessions should be able to invoke it by name
+
+**Create or update an instruction** (`.github/instructions/{name}.instructions.md`) when:
+- The rule should apply automatically based on file patterns (`applyTo`) or globally
+- It's a coding convention, architectural constraint, or process rule
+- It doesn't need to be invoked on demand
+
+## Procedure
+
+### 1. Identify the Learning
+
+Reflect on what went wrong or what was discovered:
+- What was the problem or unexpected behavior?
+- Why was it a problem? (root cause, not symptoms)
+- How was it fixed or what's the correct approach?
+- Can it be generalized beyond this specific instance?
+
+### 2. Check for Existing Files
+
+Before creating new files, search for existing skills and instructions that might be the right home:
+
+```
+# Check existing skills
+ls .github/skills/ .agents/skills/ 2>/dev/null
+
+# Check existing instructions
+ls .github/instructions/ 2>/dev/null
+
+# Search for related content
+grep -r "related-keyword" .github/skills/ .github/instructions/ .agents/skills/
+```
+
+### 3a. Add to Existing File
+
+If an appropriate file exists, add the learning to its `## Learnings` section (create the section if it doesn't exist). Each learning should be 1-4 sentences.
+
+### 3b. Create a New Skill
+
+If the knowledge warrants a standalone skill:
+
+1. Choose the location:
+   - `.github/skills/{name}/SKILL.md` for project-level skills (committed to repo)
+   - `.agents/skills/{name}/SKILL.md` for agent-specific skills
+2. Create the directory and SKILL.md with frontmatter:
+
+```markdown
+---
+name: {skill-name}
+description: {One-line description of when and why to use this skill.}
+---
+
+# {Skill Title}
+
+{Body with guidelines, procedures, examples, and learnings.}
+```
+
+3. The `name` field **must match** the parent folder name exactly.
+4. Include concrete examples — skills with examples are far more useful than abstract rules.
+
+### 3c. Create a New Instruction
+
+If the knowledge should apply automatically:
+
+```markdown
+---
+description: {When these instructions should be loaded}
+applyTo: '{glob pattern}' # optional — auto-load when matching files are attached
+---
+
+{Content of the instruction.}
+```
+
+### 4. Quality Checks
+
+Before saving:
+- Is the learning **general enough** to help future sessions, not just this one?
+- Is it **specific enough** to be actionable, not just a vague principle?
+- Does it include a **concrete example** of right vs wrong?
+- Does it avoid duplicating knowledge already captured elsewhere?
+- Is the description clear enough that the agent will know **when** to invoke/apply it?
+
+### 5. Inform the User
+
+After creating or updating the file:
+- Summarize what was captured and where
+- Explain why this location was chosen
+- Note if any existing content was updated vs new content created