| name | release-notes |
| description | Generate user-facing release notes for the Bulk Properties Obsidian plugin by examining merged PRs since the last GitHub release. Invoke manually with /release-notes when preparing a new release. |
| invoke | user |
Release Notes Generator
Generate release notes by gathering merged PRs since the last GitHub release, categorizing them by impact, and writing a concise markdown summary focused on what matters to plugin users.
Process
1. Find the latest release tag
gh release view --latest --json tagName
Then get the committer date of that tag's commit (not the release publish date, which can differ if the release was drafted first and published later; and not the author date, which can be stale if the commit was rebased or cherry-picked):
git log -1 --format=%cI TAG_NAME
2. Gather merged PRs since that tag
gh pr list --state merged --search "merged:>TAG_COMMIT_DATE" --json number,title,body,mergedAt --limit 100
Replace TAG_COMMIT_DATE with the commit date from step 1 (ISO date format).
3. Analyze each PR
For each PR, read its title and body to understand the change. If the title and body don't make the user-facing impact clear, check the diff:
gh pr diff NUMBER
Classify each PR into one of these categories:
- New Features — entirely new capabilities that didn't exist before
- Enhancements — improvements to existing features (better UX, new options, performance gains)
- Bug Fixes — corrections to broken behavior
- Other — notable changes that don't fit the categories above but users might still care about
Skip entirely any PR that falls into these categories:
- No user-facing impact: CI changes, internal refactors, dependency bumps, code cleanup, README-only updates
- Accessibility improvements: Obsidian itself has limited accessibility support, so plugin accessibility work is not meaningful to highlight in release notes
When in doubt about whether something is user-facing, lean toward including it in "Other" rather than omitting it — the user can always trim later.
If multiple PRs together form a single user-visible change (e.g., a feature PR + a follow-up fix), combine them into one bullet.
4. Write the release notes
Generate the filename using the current date and time:
date +%Y-%m-%d-%H%M
Save to: /Users/gary/Documents/Notes/0-Inbox/bulk-properties-release-notes-YYYY-MM-DD-HHmm.md
For example: bulk-properties-release-notes-2026-04-03-1435.md
Output format
# Bulk Properties Release Notes
## New Features
- **Feature name** — One sentence describing what's new.
## Enhancements
- **Enhancement name** — One sentence on what improved.
## Bug Fixes
- **Fix description** — One sentence on what was broken and how it's fixed.
## Other
- **Change name** — One sentence on what changed.
Writing guidelines
- Write for plugin users, not developers. Describe what they can now do, not how it was implemented.
- Keep each bullet to one sentence. Give a high-level overview of the change — don't describe every detail of how it works. For example, write "Tags and list properties now use a pill-style input matching Obsidian's native editor" rather than also explaining what happens on Enter, comma, paste, the validation behavior, etc.
- Omit any section that has no entries — don't include empty sections.
- Do not include PR numbers. End-users don't track PRs.
- Do not include a version number in the heading. These notes are for unreleased work — the actual version will be decided later.
- Use sentence case for descriptions.
- Avoid jargon like "frontmatter," "processFrontMatter," "serialization," "copy-on-write" — translate into plain language (e.g., "property values" instead of "frontmatter fields").
