write-changelog
Write a CHANGELOG.md entry for a new extension release. Use when: writing changelog, updating changelog, adding release notes, preparing a release, documenting milestone changes. Requires a milestone name and extension version number.
- License 许可
- MIT
- 最近更新
- 2026-11-11
- Stars
- ★ 2.6k
- Forks
- 817
01 前言 Front Matter
- name
- write-changelog
- description
- Write a CHANGELOG.md entry for a new extension release. Use when: writing changelog, updating changelog, adding release notes, preparing a release, documenting milestone changes. Requires a milestone name and extension version number.
- argument-hint
- Provide the extension version (e.g. 0.134.0) and the GitHub milestone name (e.g. 1.112.0)
02 资源文件 18
- 资产文件data/domain-complexity.csv7.2 KB
- 参考文档data/prd-purpose.md7.1 KB
- 资产文件data/project-types.csv3.1 KB
- 参考文档steps-v/step-v-01-discovery.md7.0 KB
- 参考文档steps-v/step-v-02-format-detection.md6.4 KB
- 参考文档steps-v/step-v-02b-parity-check.md6.3 KB
- 参考文档steps-v/step-v-03-density-validation.md5.6 KB
- 参考文档steps-v/step-v-04-brief-coverage-validation.md7.0 KB
- 参考文档steps-v/step-v-05-measurability-validation.md6.9 KB
- 参考文档steps-v/step-v-06-traceability-validation.md7.1 KB
- 参考文档steps-v/step-v-07-implementation-leakage-validation.md6.8 KB
- 参考文档steps-v/step-v-08-domain-compliance-validation.md7.5 KB
- 参考文档steps-v/step-v-09-project-type-validation.md8.4 KB
- 参考文档steps-v/step-v-10-smart-validation.md6.6 KB
- 参考文档steps-v/step-v-11-holistic-quality-validation.md8.5 KB
- 参考文档steps-v/step-v-12-completeness-validation.md8.0 KB
- 参考文档steps-v/step-v-13-report-complete.md7.9 KB
- 参考文档workflow.md2.8 KB
03 SKILL.md 正文
Write Changelog Entry
Generate a new entry in CHANGELOG.md for an extension release by gathering closed issues and merged PRs from a GitHub milestone.
Inputs
The user must provide:
- Extension version number - the version for the changelog heading (e.g.
0.134.0) - GitHub milestone name - the milestone to query (e.g.
1.112.0)
Procedure
1. Gather Milestone Items
Search for all closed items in the milestone scoped to microsoft/vscode-pull-request-github:
- Issues (bugs/features): Search for closed issues with
milestone:"<name>" repo:microsoft/vscode-pull-request-github is:closed - Merged PRs: Search for merged PRs with
milestone:"<name>" repo:microsoft/vscode-pull-request-github is:pr is:merged
2. Classify Items
Sort every item into one of these buckets:
| Bucket | Criteria |
|---|---|
| Changes | Feature requests, enhancements, new settings, new commands, infrastructure improvements (e.g. dependency upgrades, build system changes) |
| Fixes | Items labeled bug, or PRs that fix a specific issue |
| Thank You | Merged PRs authored by external contributors (user type is not Bot, and user is not a GitHub staff / site_admin) |
| Skip | Version-bump PRs (title is just a version like "0.132.0"), test plan items, items from other repos |
3. Write the Entry
Insert the new section at the top of CHANGELOG.md, directly after the # Changelog heading and before the previous release section.
Follow this format exactly:
## <version>
### Changes
- Description of change one.
- Description of change two with setting `"settingName"`.
### Fixes
- Short description of bug. https://github.com/microsoft/vscode-pull-request-github/issues/<number>
- Another bug fix. https://github.com/microsoft/vscode-pull-request-github/issues/<number>
**_Thank You_**
* [@username (Display Name)](https://github.com/username): Short description of contribution [PR #1234](https://github.com/microsoft/vscode-pull-request-github/pull/1234)
Format Rules
- Changes: Write a concise, user-facing description. Do NOT link to issues. Use backticks for setting names and commands. Each entry is a single
-bullet. - Fixes: Use the issue title (cleaned up for readability) followed by a space and the full issue URL. Each entry is a single
-bullet. If a fix came from a PR without a linked issue, describe it without a URL. - Thank You: Use
*bullets (not-). Format:[@login (Name)](profile-url): Description [PR #number](pr-url). Only include for external community contributors. - Sections: Omit any section (
### Changes,### Fixes,**_Thank You_**) if there are no items for it. - No blank lines between bullets within a section.
- One blank line between sections.
4. Validate
- Confirm the new section is positioned correctly (after
# Changelog, before the previous version). - Verify all issue/PR links are correct and point to
microsoft/vscode-pull-request-github. - Ensure no duplicate entries.
04 同仓库更多 Skills
summarize-github-issue-pr-notification
Summarizes the content of a GitHub issue, pull request (PR), or notification, providing a concise overview of the main points and key details. ALWAYS use the skill when asked to summarize an issue, PR, or notification.
suggest-fix-issue
Given the details of an issue, suggests a fix for the issue.
show-github-search-result
Summarizes the results of a GitHub search query in a human friendly markdown table that is easy to read and understand. ALWAYS use this skill when displaying the results of a GitHub search query.
form-github-search-query
Forms a GitHub search query based on a natural language query and the type of search (issue or PR). This skill helps users create effective search queries to find relevant issues or pull requests on GitHub.
create-pull-request
Create a GitHub Pull Request from the current or specified branch. Use when: opening a PR, submitting code for review, creating a draft PR, publishing a branch as a pull request, proposing changes to a repository.
address-pr-comments
Address review comments (including Copilot comments) on the active pull request. Use when: responding to PR feedback, fixing review comments, resolving PR threads, implementing requested changes from reviewers, addressing code review, fixing PR issues.