Agent Skills › foyzulkarim/claude-lens › release-notes

release-notes

GitHub

根据 git 提交记录自动生成 claude-lens 的发布说明。通过解析提交内容，按功能、修复和维护分类摘要，建议 Semver 版本，并将新条目追加至 CHANGELOG.md。

.claude/skills/release-notes/SKILL.md foyzulkarim/claude-lens

Trigger Scenarios

准备新版本发布需要生成或更新变更日志

Install

npx skills add foyzulkarim/claude-lens --skill release-notes -g -y

More Options

Non-standard path

npx skills add https://github.com/foyzulkarim/claude-lens/tree/main/.claude/skills/release-notes -g -y

Use without installing

npx skills use foyzulkarim/claude-lens@release-notes

指定 Agent (Claude Code)

npx skills add foyzulkarim/claude-lens --skill release-notes -a claude-code -g -y

安装 repo 全部 skill

npx skills add foyzulkarim/claude-lens --all -g -y

预览 repo 内 skill

npx skills add foyzulkarim/claude-lens --list

SKILL.md

Frontmatter

{
    "name": "release-notes",
    "description": "Draft a changelog for the next version of claude-lens by summarizing git commits since the last release. Use when preparing a version bump or cutting a release.",
    "disable-model-invocation": true
}

Release Notes

Draft a release changelog for claude-lens by summarizing the commits since the last release, then suggest the next semver version and prepend the entry to CHANGELOG.md at the project root.

Steps

Find the commit range. Determine the last released tag:
```
git describe --tags --abbrev=0 2>/dev/null
```
- If a tag exists, the range is <tag>..HEAD.
- If no tag exists (fresh repo), use the full history and treat the current package.json version as the baseline. Get it with: node -p "require('./package.json').version"

Collect the commits in the range:

# with a tag:
git log <tag>..HEAD --oneline --no-merges
# without a tag:
git log --oneline --no-merges

Group the commits by type, inferring the type from the message (Conventional Commits prefix if present, otherwise from the wording):
- Features — new functionality (feat, "Add", "Support")
- Fixes — bug fixes (fix, "Fix", "Correct")
- Chores / Maintenance — chore, refactor, docs, deps, tooling
- Drop noise (pure formatting/typo commits) or fold them into a related entry.
Suggest the next version from the current package.json version using semver:
- Breaking changes → major
- Any new feature → minor
- Only fixes/chores → patch
State the bump explicitly (e.g. 1.1.0 → 1.2.0) and the one reason for it.

Draft the release entry in this shape (omit empty sections):

## v<next-version> — <YYYY-MM-DD>

### Features
- <user-facing summary> (<short-sha>)

### Fixes
- <user-facing summary> (<short-sha>)

### Maintenance
- <user-facing summary> (<short-sha>)

Write the entry to CHANGELOG.md at the project root:
- If CHANGELOG.md does not exist, create it with a top-level heading:
```
# Changelog
```
- Read the current contents of CHANGELOG.md.
- Prepend the new entry (insert it immediately after the # Changelog heading line, before any existing entries) so the file stays newest-first.
- Write the updated file.
Use the Read and Write (or Edit) tools to do this — do not shell out to sed or awk.
Report to the user what was written: show the new entry inline and confirm the file was updated.

Notes

Write entries from the user's perspective (what changed for them), not a verbatim commit-message dump.
Include today's date (from the currentDate context, or date +%Y-%m-%d) in the entry heading.
Do not create the tag, bump package.json, or push anything unless the user explicitly asks — this skill only drafts and records the notes.