Merge branch 'main' into vnext

Author: ntrogh

.config/1espt/PipelineAutobaseliningConfig.yml

@@ -0,0 +1,43 @@
+## DO NOT MODIFY THIS FILE MANUALLY. This is part of auto-baselining from 1ES Pipeline Templates. Go to [https://aka.ms/1espt-autobaselining] for more details.
+
+pipelines:
+  239:
+    retail:
+      source:
+        credscan:
+          lastModifiedDate: 2024-10-11
+        eslint:
+          lastModifiedDate: 2024-10-11
+        psscriptanalyzer:
+          lastModifiedDate: 2024-10-11
+        armory:
+          lastModifiedDate: 2024-10-11
+        accessibilityinsights:
+          lastModifiedDate: 2025-06-03
+      binary:
+        credscan:
+          lastModifiedDate: 2024-10-11
+        binskim:
+          lastModifiedDate: 2025-01-09
+        spotbugs:
+          lastModifiedDate: 2024-10-11
+  237:
+    retail:
+      source:
+        credscan:
+          lastModifiedDate: 2025-08-05
+        eslint:
+          lastModifiedDate: 2025-08-05
+        psscriptanalyzer:
+          lastModifiedDate: 2025-08-05
+        armory:
+          lastModifiedDate: 2025-08-05
+        accessibilityinsights:
+          lastModifiedDate: 2025-08-05
+      binary:
+        credscan:
+          lastModifiedDate: 2025-08-05
+        binskim:
+          lastModifiedDate: 2025-08-05
+        spotbugs:
+          lastModifiedDate: 2025-08-05

.config/guardian/.gdnbaselines

@@ -0,0 +1,29 @@
+{
+  "properties": {
+    "helpUri": "https://eng.ms/docs/microsoft-security/security/azure-security/cloudai-security-fundamentals-engineering/security-integration/guardian-wiki/microsoft-guardian/general/baselines"
+  },
+  "version": "1.0.0",
+  "baselines": {
+    "default": {
+      "name": "default",
+      "createdDate": "2025-08-05 08:36:03Z",
+      "lastUpdatedDate": "2025-08-05 08:36:03Z"
+    }
+  },
+  "results": {
+    "a25577ddc699e709832bc436bbe266a47aa2e7fd72110237d621acaa8a858ec0": {
+      "signature": "a25577ddc699e709832bc436bbe266a47aa2e7fd72110237d621acaa8a858ec0",
+      "alternativeSignatures": [],
+      "target": ".git/lfs/logs/20250805T083310.2996896.log",
+      "line": 78,
+      "memberOf": [
+        "default"
+      ],
+      "tool": "credscan",
+      "ruleId": "CSCAN-GENERAL0120",
+      "createdDate": "2025-08-05 08:36:03Z",
+      "expirationDate": "2026-01-22 08:42:50Z",
+      "justification": "This error is baselined with an expiration date of 180 days from 2025-08-05 08:42:50Z"
+    }
+  }
+}

.gitattributes

@@ -4,7 +4,8 @@
 *.jpg filter=lfs diff=lfs merge=lfs -text
 *.png filter=lfs diff=lfs merge=lfs -text
 *.md diff=markdown
-
 # Fine-tune GitHub's language detection
 docs/** -linguist-documentation
 *.md linguist-detectable
+/workspaces/vscode-docs/docs/copilot/images/overview/configure-completions.png filter=lfs diff=lfs merge=lfs -text
+/workspaces/vscode-docs/docs/copilot/images/overview/change-completions-model.png filter=lfs diff=lfs merge=lfs -text

.github/copilot-instructions.md

@@ -0,0 +1,3 @@
+# VS Code Docs Writing Guidelines
+
+Follow the [documentation writing guidelines](../instructions/docs-writing.instructions.md) when reviewing or writing documentation.

.github/instructions/docs-writing.instructions.md

@@ -0,0 +1,102 @@
+---
+applyTo: '**/*.md'
+---
+# Documentation Writing Instructions
+
+These are our documentation writing style guidelines.
+
+## General Style tips
+
+* Get to the point fast.
+* Talk like a person.
+* Simpler is better.
+* Be brief. Give customers just enough information to make decisions confidently. Prune every excess word.
+
+## Grammar
+
+* Use present tense verbs (is, open) instead of past tense (was, opened).
+* Write factual statements and direct commands. Avoid hypotheticals like "could" or "would".
+* Use active voice where the subject performs the action.
+* Write in second person (you) to speak directly to readers.
+* Use gender-neutral language.
+* Avoid multiple -ing words that can create ambiguity.
+* Keep prepositional phrases simple and clear.
+* Place modifiers close to what they modify.
+
+## Capitalization
+
+* Use sentence-style capitalization for everything except proper nouns.
+* Always capitalize proper nouns.
+* Don’t capitalize the spelled-out form of an acronym unless it's a proper noun.
+* Use title-style capitalization for product and service names.
+* In programming languages, follow the traditional capitalization of keywords and other special terms.
+* Don't use all uppercase for emphasis.
+
+## Numbers
+
+* Spell out numbers for zero through nine, unless space is limited. Use numerals for 10 and above.
+* Spell out numbers at the beginning of a sentence.
+* Spell out ordinal numbers such as first, second, and third. Don't add -ly to form adverbs from ordinal numbers.
+
+## Punctuation
+
+* Use short, simple sentences.
+* End all sentences with a period.
+* Use one space after punctuation marks.
+* After a colon, capitalize only proper nouns.
+* Avoid semicolons - use separate sentences instead.
+* Use question marks sparingly.
+* Don't use slashes (/) - use "or" instead.
+
+## Text formatting
+
+* UI elements, like menu items, dialog names, and names of text boxes, should be in bold text.
+* Use code style for:
+    * Code elements, like method names, property names, and language keywords.
+    * SQL commands.
+    * NuGet package names.
+    * Command-line commands.
+    * Database table and column names.
+    * Resource names (like virtual machine names) that shouldn't be localized.
+    * URLs that you don't want to be selectable.
+* For code placeholders, if you want users to replace part of an input string with their own values, use angle brackets (less than < and greater than > characters) on that placeholder text.
+* Don't apply an inline style like italic, bold, or inline code style to headings.
+
+## Alerts
+
+* Alerts are a Markdown extension to create block quotes that render with colors and icons that indicate the significance of the content. The following alert types are supported:
+
+    * `[!NOTE]` Information the user should notice even if skimming.
+    * `[!TIP]` Optional information to help a user be more successful.
+    * `[!IMPORTANT]` Essential information required for user success.
+    * `[!CAUTION]` Negative potential consequences of an action.
+    * `[!WARNING]` Dangerous certain consequences of an action.
+
+## Links
+
+* Links to other documentation articles should be relative, not absolute. Start relative links with `/docs/` and include the `.md` suffix.
+* Links in release notes should be full URLs, not relative. Use the `https://code.visualstudio.com/docs/` domain.
+* Links to bookmarks within the same article should be relative and start with `#`.
+* Link descriptions should be descriptive and make sense on their own. Don't use "click here" or "this link" or "here".
+
+## Images
+
+* Use images only when they add value.
+* Images have a descriptive and meaningful alt text that starts with "Screenshot showing" and ends with ".".
+* Videos have a descriptive and meaningful alt text or title that starts with "Video showing" and ends with ".".
+
+## Numbered steps
+
+* Write complete sentences with capitalization and periods
+* Use imperative verbs
+* Clearly indicate where actions take place (UI location)
+* For single steps, use a bullet instead of a number
+* When allowed, use angle brackets for menu sequences (File > Open)
+
+## Terminology
+
+* Use "Select" instead of "Click" for UI elements like buttons, menu items, links, dropdowns, and checkboxes.
+* Use "might" instead of "may" for conditional statements.
+* Avoid latin abbreviations like "e.g.". Use "for example" instead.
+* Use the verb "to enable" instead "to allow" unless you're referring to permissions.
+* Follow the terms and capitalization guidelines in #fetch [VS Code docs wiki](https://github.com/microsoft/vscode-docs/wiki/VS-Code-glossary)

.github/instructions/release-notes-writing.instructions.md

@@ -0,0 +1,77 @@
+# VS Code Release Notes Writing Guide
+
+## Introduction
+
+You are a technical writer assistant tasked with generating release notes for all requested VS Code features.
+
+## Key Principles
+
+1. Identifying the Release Notes file to write to:
+    - Use `getCurrentMilestone` tool to identify the current milestone name.
+    - Search for the release notes file under `release-notes` folder. Please note that the file name is not same as the milestone name. So you need to do full text search to find the file. The release notes file for give milestone will contain following text: `TOCTitle:` followed by the milestone name. Example text in the file: `TOCTitle: April 2016`.
+    - If the file does not exist, create a new file with appropriate file name.
+
+2. Identifying Features to Document:
+    - Use `getCurrentMilestone` tool to identify the current milestone.
+    - Use the `getReleaseFeatures` tool to retrieve all features and all of them must be documented.
+    - Each feature includes a `labels` property, which lists all labels associated with it.
+    - A feature is identified by one of the following labels:
+        - `feature-request`: Represents a standard feature request issue. Its description and comments contain detailed information about the feature.
+        - `testplan-item`: Represents a structured testing plan for the feature. Its description contains in-depth details about the feature and set up and steps to test it.
+    - Each feature also includes a `related` property, which lists related issues that provide additional context or details about the feature.
+    - Generate release notes for all features.
+
+3. Feature Section Structure:
+    - To create a complete feature section, gather and analyze all relevant details from the following:
+        - The summary, description, and comments of the feature itself.
+        - If there are any related issues, the summary, description, and comments from all related issues.
+    - Each feature section should provide a comprehensive and user-focused overview.
+    - The title and description should not include anything related to testing, such as setup, test instructions, or validation steps.
+    - Feature Title
+        - Use a concise, descriptive title that clearly identifies the feature itself
+        - Do not the take the title from the test plan item feature because it is meant for testing.
+    - Feature Description
+        - Provide a comprehensive explanation of the feature and its purpose.
+        - Should include all additional and relevant information
+        - Should include all constraints those users should be aware of.
+        - Clearly state if the feature is in Preview or Experimental, if applicable.
+        - Do not add Feature Description Header
+
+## Important Guidelines
+
+1. Settings and Commands:
+    - Only document settings that actually exist in VS Code
+    - Verify all setting names and values before documenting
+    - Double-check command IDs before referencing them
+    - Use the search tools to confirm setting/command existence
+
+1. Quality Control:
+    - Save changes using provided tools
+    - Verify all links and references
+    - Ensure consistency with existing docs
+    - Fact-check all technical details
+
+1. Write to release notes
+    - Write ONLY the feature documentation sections
+    - DO NOT include version headers, welcome messages, or update summaries
+    - Start directly with ### feature headings
+    - Use the write tools to write to the release notes
+    - Do not ask for user confirmation
+
+## Writing Guidelines
+
+Apply these specific guidelines to all release notes. For other text, follow the general [writing guidelines](../copilot-instructions.md).
+
+### Headings
+
+- Don't apply an inline style like italic, bold, or inline code style to headings.
+- Lowercase everything except the first word in a heading.
+
+### Links
+
+- Links to other documentation articles should be absolute, not relative. Start absolute links with `https://code.visualstudio.com/docs/` and don't include the `.md` suffix.
+- Link text should be descriptive and clearly indicate the content of the linked article. Don't use "click here" or "this link" or "here".
+
+### Text Formatting
+
+- Notes and tips are formatted as block quotes with the word "Note" or "Tip" in bold at the start of the line. Don't use alert-style formatting for these.

.github/prompts/generate-release-notes.prompt.md

@@ -0,0 +1,5 @@
+---
+mode: 'agent'
+tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'readCellOutput', 'runCommands', 'runNotebooks', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'updateUserPreferences', 'usages', 'vscodeAPI', 'Figma', 'getCurrentMilestone', 'getReleaseFeatures']
+---
+Generate release notes for the features I worked in the current release and update them in the release notes file. Use [release notes writing instructions file](../instructions/release-notes-writing.instructions.md) as a guide.

.github/prompts/review-article.prompt.md

@@ -0,0 +1,10 @@
+---
+mode: agent
+tools: ['codebase', 'vscodeAPI', 'problems', 'fetch', 'search']
+description: You are a technical writer reviewing an article for clarity, conciseness, and adherence to the documentation writing style guidelines.
+---
+Review the article for clarity, conciseness, and adherence to our documentation [writing style guidelines](../instructions/docs-writing.instructions.md).
+
+Provide concrete and practical suggestions for improvement.
+
+Provide your feedback in the form of a Markdown task list, with each task starting with `- [ ]`.

.husky/post-checkout

@@ -1,3 +1,3 @@
 #!/bin/sh
-command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-checkout' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
+command -v git-lfs >/dev/null 2>&1 || { printf >&2 "\n%s\n\n" "This repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-checkout' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks')."; exit 2; }
 git lfs post-checkout "$@"

.husky/post-commit

@@ -1,3 +1,3 @@
 #!/bin/sh
-command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-commit' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks').\n"; exit 2; }
+command -v git-lfs >/dev/null 2>&1 || { printf >&2 "\n%s\n\n" "This repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting the 'post-commit' file in the hooks directory (set by 'core.hookspath'; usually '.git/hooks')."; exit 2; }
 git lfs post-commit "$@"