debt - improve workspace settings and copilot configuration (microsoft#255359)

Author: bpasero

.github/chatmodes/learn.chatmode.md

@@ -2,6 +2,7 @@
 description: 'Save learnings from conversation'
 tools: ['codebase', 'editFiles', 'githubRepo', 'runCommands', 'search', 'searchResults', 'usages']
 ---
+# Learn mode instructions
 Please take a moment and deeply reflect on all the steps you took and think if there would have been a piece of information which would have allowed you to work faster (take less steps).
 
-The file .vscode/project.instructions.md has been already provided to you. Edit the file such that it would contain information which would have made you work faster. Please don't make this too specific to this task, but rather something that is generic but useful enought to ensure speed-ups in the future for other tasks.
+The file .github/copilot-instructions.md has been already provided to you. Edit the file such that it would contain information which would have made you work faster. Please don't make this too specific to this task, but rather something that is generic but useful enought to ensure speed-ups in the future for other tasks.

.github/chatmodes/plan.chatmode.md

@@ -1,5 +1,20 @@
 ---
 description: 'Plan the solution for a problem.'
-tools: ['codebase', 'findTestFiles', 'githubRepo', 'search', 'searchResults', 'usages']
+tools: ['codebase', 'fetch', 'findTestFiles', 'githubRepo', 'get_issue', 'get_issue_comments', 'get_me', 'search', 'searchResults', 'usages', 'vscodeAPI']
 ---
-I need your help with the following problem. Please take a look, understand the request in depth, and if the request makes sense, research it, understand the existing code, then suggest a clear plan with steps to take to address the request.
+# Planning mode instructions
+You are an expert software engineer tasked with fixing a bug or adding a new feature in the codebase.
+Your goal is to prepare a detailed plan to fix the bug or add the new feature, for this you first need to:
+* Understand the context of the bug by reading the issue description and comments.
+* Understand the codebase by reading the relevant instruction files.
+* If its a bug, then identify the root cause of the bug, and explain this to the user.
+
+Based on your above understanding generate a plan to fix the bug or add the new feature.
+Ensure the plan consists of a Markdown document that has the following sections:
+
+* Overview: A brief description of the bug/feature.
+* Root Cause: A detailed explanation of the root cause of the bug, including any relevant code snippets or references to the codebase. (only if it's a bug)
+* Requirements: A list of requirements to resolve the bug or add the new feature.
+* Implementation Steps: A detailed list of steps to implement the bug fix or new feature.
+
+Remember, do not make any code edits, just generate a plan.

.github/copilot-instructions.md

@@ -1,57 +1,115 @@
-# Coding Guidelines
-
-## Introduction
-
-These are VS Code coding guidelines. Please also review our [Source Code Organisation](https://github.com/microsoft/vscode/wiki/Source-Code-Organization) page.
-
-## Indentation
+# VS Code Copilot Instructions
+
+## Project Overview
+
+Visual Studio Code is built with a layered architecture using TypeScript, web APIs and Electron, combining web technologies with native app capabilities. The codebase is organized into key architectural layers:
+
+### Root Folders
+- `src/`: Main TypeScript source code with unit tests in `src/vs/*/test/` folders
+- `build/`: Build scripts and CI/CD tools
+- `extensions/`: Built-in extensions that ship with VS Code
+- `test/`: Integration tests and test infrastructure
+- `scripts/`: Development and build scripts
+- `resources/`: Static resources (icons, themes, etc.)
+- `out/`: Compiled JavaScript output (generated during build)
+
+### Core Architecture (`src/` folder)
+- `src/vs/base/` - Foundation utilities and cross-platform abstractions
+- `src/vs/platform/` - Platform services and dependency injection infrastructure
+- `src/vs/editor/` - Text editor implementation with language services, syntax highlighting, and editing features
+- `src/vs/workbench/` - Main application workbench for web and desktop
+  - `workbench/browser/` - Core workbench UI components (parts, layout, actions)
+  - `workbench/services/` - Service implementations
+  - `workbench/contrib/` - Feature contributions (git, debug, search, terminal, etc.)
+  - `workbench/api/` - Extension host and VS Code API implementation
+- `src/vs/code/` - Electron main process specific implementation
+- `src/vs/server/` - Server specific implementation
+
+The core architecture follows these principles:
+- **Layered architecture** - from `base`, `platform`, `editor`, to `workbench`
+- **Dependency injection** - Services are injected through constructor parameters
+- **Contribution model** - Features contribute to registries and extension points
+- **Cross-platform compatibility** - Abstractions separate platform-specific code
+
+### Built-in Extensions (`extensions/` folder)
+The `extensions/` directory contains first-party extensions that ship with VS Code:
+- **Language support** - `typescript-language-features/`, `html-language-features/`, `css-language-features/`, etc.
+- **Core features** - `git/`, `debug-auto-launch/`, `emmet/`, `markdown-language-features/`
+- **Themes** - `theme-*` folders for default color themes
+- **Development tools** - `extension-editing/`, `vscode-api-tests/`
+
+Each extension follows the standard VS Code extension structure with `package.json`, TypeScript sources, and contribution points to extend the workbench through the Extension API.
+
+### Finding Related Code
+1. **Semantic search first**: Use file search for general concepts
+2. **Grep for exact strings**: Use grep for error messages or specific function names
+3. **Follow imports**: Check what files import the problematic module
+4. **Check test files**: Often reveal usage patterns and expected behavior
+
+## Coding Guidelines
+
+### Indentation
 
 We use tabs, not spaces.
 
-## Naming Conventions
+### Naming Conventions
+
+- Use PascalCase for `type` names
+- Use PascalCase for `enum` values
+- Use camelCase for `function` and `method` names
+- Use camelCase for `property` names and `local variables`
+- Use whole words in names when possible
 
-* Use PascalCase for `type` names
-* Use PascalCase for `enum` values
-* Use camelCase for `function` and `method` names
-* Use camelCase for `property` names and `local variables`
-* Use whole words in names when possible
+### Types
 
-## Types
+- Do not export `types` or `functions` unless you need to share it across multiple components
+- Do not introduce new `types` or `values` to the global namespace
 
-* Do not export `types` or `functions` unless you need to share it across multiple components
-* Do not introduce new `types` or `values` to the global namespace
+### Comments
 
-## Comments
+- Use JSDoc style comments for `functions`, `interfaces`, `enums`, and `classes`
 
-* When there are comments for `functions`, `interfaces`, `enums`, and `classes` use JSDoc style comments
+### Strings
 
-## Strings
+- Use "double quotes" for strings shown to the user that need to be externalized (localized)
+- Use 'single quotes' otherwise
+- All strings visible to the user need to be externalized
 
-* Use "double quotes" for strings shown to the user that need to be externalized (localized)
-* Use 'single quotes' otherwise
-* All strings visible to the user need to be externalized
+### UI labels
+- Use title-style capitalization for command labels, buttons and menu items (each word is capitalized).
+- Don't capitalize prepositions of four or fewer letters unless it's the first or last word (e.g. "in", "with", "for").
 
-## Style
+### Style
 
-* Use arrow functions `=>` over anonymous function expressions
-* Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:
+- Use arrow functions `=>` over anonymous function expressions
+- Only surround arrow function parameters when necessary. For example, `(x) => x + x` is wrong but the following are correct:
 
-```javascript
+```typescript
 x => x + x
 (x, y) => x + y
 <T>(x: T, y: T) => x === y
 ```
 
-* Always surround loop and conditional bodies with curly braces
-* Open curly braces always go on the same line as whatever necessitates them
-* Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:
+- Always surround loop and conditional bodies with curly braces
+- Open curly braces always go on the same line as whatever necessitates them
+- Parenthesized constructs should have no surrounding whitespace. A single space follows commas, colons, and semicolons in those constructs. For example:
 
-```javascript
+```typescript
 for (let i = 0, n = str.length; i < 10; i++) {
     if (x < 10) {
         foo();
     }
 }
-
 function f(x: number, y: string): void { }
 ```
+
+- Whenever possible, use in top-level scopes `export function x(…) {…}` instead of `export const x = (…) => {…}`. One advantage of using the `function` keyword is that the stack-trace shows a good name when debugging.
+
+### Code Quality
+
+- All files must include Microsoft copyright header
+- Prefer async/await over Promises, handle cancellation with `CancellationToken`
+- All user facing messages must be localized using the applicable localization framework (for example `nls.localize()` method)
+- Don't add tests to the wrong test suite (e.g., adding to end of file instead of inside relevant suite)
+- Look for existing test patterns before creating new structures
+- Use `describe` and `test` consistently with existing patterns

.github/instructions/typescript.instructions.md

@@ -0,0 +1,29 @@
+---
+applyTo: '**/*.ts'
+---
+
+# VS Code Copilot Development Instructions
+
+## ⚠️ MANDATORY COMPILATION CHECK
+
+**CRITICAL: You MUST check compilation output before running ANY script or declaring work complete!**
+
+### Before running any command:
+1. **ALWAYS** check the "Core - Build" task output for compilation errors
+2. **ALWAYS** check the "Ext - Build" task output for compilation errors
+3. **NEVER** run tests if there are compilation errors
+4. **FIX** all compilation errors before moving forward
+
+## Scripts
+- Use `npm install` to install dependencies if you changed `package.json`
+- Use `scripts/test.sh` (or `scripts\test.bat` on Windows) for unit tests (add `--grep <pattern>` to filter tests)
+- Use `scripts/test-integration.sh` (or `scripts\test-integration.bat` on Windows) for integration tests
+- Use `npm run valid-layers-check` to check for layering issues
+
+## Compilation Tasks
+Typescript compilation errors can be found by running the "Core - Build" and "Ext - Build" tasks:
+- **Core - Build**: Compiles the main VS Code TypeScript sources
+- **Ext - Build**: Compiles the built-in extensions
+- These background tasks may already be running from previous development sessions
+- If not already running, start them to get real-time compilation feedback
+- The tasks provide incremental compilation, so they will automatically recompile when files change