Agent Skills
› NeverSight/learn-skills.dev
› changelog-from-tags
changelog-from-tags
GitHub用于更新 Dart/Flutter 包的 CHANGELOG.md。通过比较上一个稳定发布标签与当前分支的差异，生成包含用户影响、PR链接的准确发布说明，并自动更新或新增版本条目。
Trigger Scenarios
查找自上次发布以来的变更
生成或更新发布说明
更新 CHANGELOG.md
查询版本间差异
Install
npx skills add NeverSight/learn-skills.dev --skill changelog-from-tags -g -y
SKILL.md
Frontmatter
{
"name": "changelog-from-tags",
"description": "Update a Dart\/Flutter package's CHANGELOG.md by computing changes between the previous released git tag and the current branch\/HEAD. Use this whenever the user asks to “find changes since last release tag”, “generate\/update release notes”, “update CHANGELOG.md”, or “what changed between versions” for a package folder in a git repo (especially Flutter\/Dart packages)."
}
changelog-from-tags
Goal
Given a package directory inside a git repo, find the previous released
version tag, compute what changed since that tag (preferably scoped to the
package directory), then update the package's CHANGELOG.md latest entry
with accurate release notes.
Assumptions
- The package is a folder in a git repo and has:
pubspec.yamlCHANGELOG.md
- Tags in the repo follow SemVer-ish names (e.g.
2.1.7,2.1.7+1,2.1.7-dev.1).
Workflow
1) Identify the target package and its current version
- Read
<package>/pubspec.yaml. - Record
version:ascurrentVersion.
2) Identify the “previous released version tag”
- List tags sorted by version descending.
- Example:
git -C <package> tag --list --sort=-v:refname
- Example:
- Prefer the latest stable tag (no
-dev,-alpha,-beta,-rc), unless the user explicitly requests a pre-release comparison. - Confirm what tag points at
HEAD(if any). IfHEADis already tagged, your diff range should usually still bepreviousTag..HEAD(unless user asked fortagA..tagB).
3) Collect changes since previous tag (package-scoped)
- Gather commit list affecting only the package directory:
git -C <package> log <previousTag>..HEAD --oneline --decorate -- . - Gather a stat summary:
git -C <package> diff --stat <previousTag>..HEAD -- . - If needed, inspect diffs of relevant files (e.g.
pubspec.yaml, platform code folders, README).
Optional helper (no extra dependencies):
If you want a single command to print the scoped commits and diffstat, run:
.agents\skills\changelog-from-tags\scripts\collect_changes.cmd <path-to-package>
4) Update CHANGELOG.md
- Read
<package>/CHANGELOG.mdand identify the topmost version header. - Decide the target section to update:
- If the topmost section matches
currentVersion, update that section. - Otherwise, add a new top section
## <currentVersion>(or## Unreleasedif the repo uses that convention) and place notes there.
- If the topmost section matches
- Write release notes based on actual changes between tags:
- Prefer user-facing impact.
- Keep bullets concise.
- Include PR/issue links when present in commit messages or known references.
- Avoid guessing. If the diff only changes dependency constraints/lockfiles, say so.
5) Sanity checks
- Ensure
CHANGELOG.mdremains valid Markdown. - Show
git diff -- <package>/CHANGELOG.mdfor review.
Output expectations
When done, report:
- Previous tag used (e.g.
2.1.7) - Diff range (e.g.
2.1.7..HEAD) - A short bullet list of what was added to the changelog
- The updated file path
Edge cases & guidance
- Monorepo tags: If tags are global but package changes are scoped, always
scope logs/diffs to the package directory (
-- .) to avoid unrelated changes. - No tags: If no tags exist, treat all history as changes and create an initial changelog entry.
- Mismatch between tag and pubspec version: If
pubspec.yamlversion is not newer than the latest stable tag, ask the user whether to update the existing top section or create a new one.
Version History
- e0220ca Current 2026-07-05 22:03
