Skip to main content

release-notes

Generate release notes between two git tags and publish as a GitHub release. Input format: "<new-tag> from <base-tag>" (e.g. "v0.5.2 from v0.5.0").

소스 정보

저장소
griddynamics/specflow
최근 소스 활동
2026년 6월 30일 09:29
감지된 SKILL.md 언어
영어
스타
9
포크
2

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
release-notes
description
Generate release notes between two git tags and publish as a GitHub release. Input format: "<new-tag> from <base-tag>" (e.g. "v0.5.2 from v0.5.0").
# Release Notes Generator ## Steps 1. Parse args to extract `NEW_TAG` and `BASE_TAG` (format: `v0.5.2 from v0.5.0`). 2. Run `git log <BASE_TAG>..<NEW_TAG> --oneline --merges` to list merge commits (PRs). 3. For each merge commit, extract the PR number and title using `gh pr view <number> --json number,title,author` — match PR numbers from commit messages like `#123` or `Merge pull request #123`. 4. If no PR number is found in a merge commit, use the commit subject as the entry with the committer as author. 5. Write release notes in the format below. 6. Publish the GitHub release: `gh release create <NEW_TAG> --title "<title>" --notes "<body>"`. - If the tag does not yet exist on the remote, add `--target main` (or the default branch). - If the release already exists, use `gh release edit <NEW_TAG> --notes "<body>"` instead. 7. Print the release URL from the `gh` output. ## Output Format ``` ## <NEW_TAG> — <short label derived from the tag, e.g. "0.5.2"> <2-3 sentence Slack-ready summary. What shipped, why it matters, any breaking changes. Plain prose, no bullet points. No internal jargon.> ## What's Changed - <PR title> by @<author> in #<number> - <PR title> by @<author> in #<number> ... **Full Changelog**: https://github.com/<owner>/<repo>/compare/<BASE_TAG>...<NEW_TAG> ``` ## Rules - Derive `<owner>/<repo>` from `gh repo view --json nameWithOwner -q .nameWithOwner`. - Release title format: `<NEW_TAG>` (just the tag — GitHub prepends the repo name automatically). - The Slack summary goes at the **top** of the release body, before "What's Changed". - List only PRs merged between the two tags — do not include direct commits that have no PR. - If a commit has no associated PR, skip it silently unless it's the only change, in which case list it as `- <subject> by @<author>`. - Do NOT include "Merge branch" or "Merge pull request" boilerplate lines. - The summary must be usable as-is in a Slack message — no markdown headers, no code spans. - After publishing, print the final release URL so the user can share it.
GitHub에서 보기