OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add microsoft/vscode-docs --skill release-note-writer
Guidelines for writing and reviewing Insiders and Stable release notes for Visual Studio Code. This also includes instructions for updating release notes for recovery releases.
npx skills add microsoft/vscode-docs --skill release-note-writer
This skill is designed to help you write release notes for Visual Studio Code Insiders and Stable releases. It provides structured guidelines and examples to ensure consistency and clarity in the release notes.
There are two main types of release notes you can generate using this skill:
Insiders Release Notes: These notes cover the latest features and updates in the Insiders build of VS Code. They are updated frequently as new features are added. Their format includes sections grouped by the date of the updates. The content is generated based on closed GitHub issues and PRs for a specific milestone.
Stable Release Notes: These notes summarize the key features and improvements in a stable release of VS Code. They follow a more structured format with predefined sections for different feature areas. The release is initially created using a template and then updated by the engineering team.
Your task is help generate these release notes based on the provided guidelines, examples, and templates.
Follow the guidelines in this order of priority:
Before writing or retaining an entry, verify that the functionality is available in the public release channel covered by the notes. Public Insiders, Preview, and Experimental functionality qualifies when labeled clearly. Exclude and report internal dogfood, hidden settings or commands, source-only implementation, and manually settable internal feature flags.
Insiders release notes cover the latest features and updates in the Insiders build of VS Code. They are updated frequently as new features are added. Their format includes sections grouped by the date of the updates. The content is generated based on closed GitHub issues and PRs for a specific milestone.
Your task is to generate release notes for the specified VS Code Insiders release version based on GitHub issues and PRs.
If no release version is specified, ask the user for the release version. If no milestone name is specified, check if the milestone name is in the frontmatter, otherwise ask the user for the milestone name. If no label is specified, use the "feature-request" label by default.
DO NOT continue until you have the release version and milestone name!!
Issues are grouped in H2 sections by their closed date. The TOC must be updated to reflect the new sections and issues added.
Use this template for the Insiders release notes.
The 1.109 release notes are a concrete example of an Insiders release note.
If there is not an existing Insiders release note for the specified version, create a new release note file using the Insiders release note template and replace the placeholders.
Release notes are stored in the /release-notes folder with the filename format v<version>.md, e.g., v1_109.md.
Make sure to copy the following images to the appropriate images folder (/release-notes/images/<version with underscores>, e.g. 1_110) for the release version:
vscode-insiders-header.webpvscode-insiders-banner-medium.pngGet last update date from existing release notes for the specified release version. If no existing release notes, disregard last update date.
Run a subagent to fetch all closed GitHub issues in the microsoft/vscode repo for the milestone that have the specified label and closed date as of the latest update date by using the github CLI. Save the JSON in the release note document.
Use this CLI command: gh search issues --repo microsoft/vscode --label <label name> --milestone <milestone name> --state closed "closed:>=<latest update date>" -L 100
Verify that each candidate is available in the public Insiders build. Exclude and report internal-only candidates instead of creating entries for them.
Ignore issues that are marked as duplicate or not planned.
For each issue in the JSON result, run a subagent to update the release notes and TOC with a concise technically accurate summary of the issue. Get more details from the associated PRs if needed. At the end of the summary, include a link to the GH issue which include the issue number and title (format: #12345: Issue title). Group issues under an H2 section that represents the closed date.
Stable release notes summarize the key features and improvements in a stable release of VS Code. They follow a more structured format with predefined sections for different feature areas. The release is initially created using a template and then updated by the engineering team.
If no release version is specified, ask the user for the release version. If no release month and year are specified, ask the user for the release month and year. DO NOT continue until you have the release version and release month and year!!
Use this template for generating the initial Stable release notes.
If there is not an existing release note for the specified version, create a new release note file using the Stable release note template.
Release notes are stored in the /release-notes folder with the filename format v<version>.md, e.g., v1_109.md.
If there is an existing release note for the specified version, and it's an Insiders release note, replace the content with the Stable release note template content.
If there is an existing Stable release note for the specified version, perform a code review of the existing release note to ensure it adheres to the writing guidelines. Suggest improvements as needed.
Verify that each feature is available in the Stable release being documented. Exclude and report internal-only features, and do not infer availability from source-code existence alone.
The writing instructions define the value-proposition and feature-continuity rules. When writing Stable entries, keep these essentials top of mind:
After a first pass of all feature sections, review the draft for gaps you cannot resolve from the issue, PR, or existing docs. Batch all gaps into a single ask-questions prompt rather than interrupting per section. Ask when:
For each gap, include your best-guess draft so the user can confirm or correct rather than write from scratch.
Before asking, search the docs/ folder for any referenced concepts. If docs coverage is thorough, link to the page and skip the question. Only flag concepts where coverage is thin or absent.
When a recovery release is needed, a note is added to the top of the release notes that links to the issues resolved in the recovery release. In addition, the download version is updated to the recovery release version. The rest of the release notes remain unchanged.
Perform these steps to update the release notes for a recovery release:
Update the DownloadVersion in the frontmatter to the recovery release version.
Add a note at the top of the release notes, right after the release date, that links to the issues resolved in the recovery release:
When multiple recovery releases are needed, add the note for each recovery release in chronological order.
To review release notes, follow the full review procedure. This covers both standalone review and post-write validation, with checklists for Insiders and Stable release notes.