release-note-writer
Provides structured guidelines for drafting VS Code release notes. Ensures clarity and consistency across release types.
Install
mkdir -p .claude/skills/release-note-writer && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4043" && unzip -o skill.zip -d .claude/skills/release-note-writer && rm skill.zipInstalls to .claude/skills/release-note-writer
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guidelines for writing and reviewing Insiders and Stable release notes for Visual Studio Code.Key capabilities
- →Structures Insiders release content by date
- →Aggregates closed GitHub issue/PR data
- →Formats Stable releases by feature area
- →Applies documentation writing guidelines
How it works
Parses milestone metadata and issue tracking data to populate pre-defined release documentation templates.
Inputs & outputs
When to use release-note-writer
- →Draft VS Code Insiders release notes
- →Prepare Stable release documentation
- →Review release note consistency
- →Format GitHub PR summaries
About this skill
Visual Studio Code Release Note Writer Guidelines
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.
General writing guidelines for release notes
Follow the guidelines in this order of priority:
Insiders Release Notes
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.
Input parameters
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!!
File format
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.
Generation steps
-
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-notesfolder with the filename formatv<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.png
-
Get 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 -
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.
Phrasing guidelines for Insiders entries
- When describing new capabilities, prefer the format "Add support for ..." over "... now supports ...". For example, write "Add support for sorting sessions by date" rather than "The sessions view now supports sorting by date".
- Avoid using the word "now" in entries. State what changed directly instead. For example, write "Branch names are generated based on the user's prompt" rather than "Branch names are now generated based on the user's prompt".
Stable Release Notes
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.
Input parameters
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!!
File format
Use this template for generating the initial Stable release notes.
Generation steps
-
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-notesfolder with the filename formatv<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.
Value proposition and feature framing
The writing instructions define the value-proposition and feature-continuity rules. When writing Stable entries, keep these essentials top of mind:
- Open each entry with the user benefit or the problem being solved, then explain mechanics.
- For multi-release features, re-establish context in 1-2 sentences so the entry stands on its own.
- For admin/policy features, cover both the admin use case and the developer-facing impact.
- Prefer concrete examples and before/after comparisons over vague claims.
Verify context gaps with the user
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:
- Value prop unclear: You cannot confidently write a benefit-first opening from the source material.
- Multi-release context missing: A feature builds on prior work but you cannot find earlier entries to reference.
- Audience ambiguous: Framing differs depending on whether the audience is developers, admins, or extension authors.
- Docs coverage thin: A feature references a concept that is undocumented or only mentioned as a sidenote, and you need guidance on how much to explain inline.
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.
Recovery release notes
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
DownloadVersionin 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:
**Update <recovery version>**: The update addresses these [issues](https://github.com/microsoft/vscode/issues?q=is%3Aissue+is%3Aclosed+milestone%3A<recovery version>).When multiple recovery releases are needed, add the note for each recovery release in chronological order.
Review Procedure
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.
When not to use it
- →General technical writing unrelated to VS Code
- →Marketing copy generation
Prerequisites
Limitations
- →Requires specific GitHub issue labels
- →Strictly constrained to template structure
How it compares
It enforces strict versioning and formatting standards specific to the VS Code release lifecycle.
Compared to similar skills
release-note-writer side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| release-note-writer (this skill) | 1 | 3mo | No flags | Beginner |
| docs-write | 22 | 6mo | No flags | Beginner |
| content-research-writer | 15 | 10mo | No flags | Beginner |
| doc-coauthoring | 16 | 8mo | No flags | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by microsoft
View all by microsoft →You might also like
docs-write
metabase
Write documentation following Metabase's conversational, clear, and user-focused style. Use when creating or editing documentation files (markdown, MDX, etc.).
content-research-writer
ComposioHQ
Assists in writing high-quality content by conducting research, adding citations, improving hooks, iterating on outlines, and providing real-time feedback on each section. Transforms your writing process from solo effort to collaborative partnership.
doc-coauthoring
anthropics
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
research-grants
davila7
Write competitive research proposals for NSF, NIH, DOE, and DARPA. Agency-specific formatting, review criteria, budget preparation, broader impacts, significance statements, innovation narratives, and compliance with submission requirements.
teams-channel-post-writer
daymade
Creates educational Teams channel posts for internal knowledge sharing about Claude Code features, tools, and best practices. Applies when writing posts, announcements, or documentation to teach colleagues effective Claude Code usage, announce new features, share productivity tips, or document lessons learned. Provides templates, writing guidelines, and structured approaches emphasizing concrete examples, underlying principles, and connections to best practices like context engineering. Activates for content involving Teams posts, channel announcements, feature documentation, or tip sharing.
write-docs
tldraw
Writing SDK documentation for tldraw. Use when creating new documentation articles, updating existing docs, or when documentation writing guidance is needed. Applies to docs in apps/docs/content/.