forge-update-changelog
Update Changelog
Update CHANGELOG.md with user-facing changes from recent development work.
Input
Primary input: optional start reference — a date (YYYY-MM-DD) or commit hash.
Optional last parameter: -- <additional context>
Interpret $ARGUMENTS as one of:
<date><commit><date> -- <additional context><commit> -- <additional context>-- <additional context>
If no start reference is provided, look at commits since the last changelog update. Use any additional context to influence grouping, emphasis, or release framing.
Process
Step 1: Read Current Changelog
Read CHANGELOG.md to understand the existing format and last update.
Step 2: Gather Recent Commits
git log --format="%h %s" --since="1 month ago"
# Or from a specific commit:
git log --oneline <commit>..HEAD
Step 3: Filter and Deduplicate
Include only changes users would notice: features, bug fixes, performance improvements.
Skip internal changes: refactors, tests, chore, CI, docs (unless user-facing help docs).
Deduplicate against existing entries. Compare each candidate commit against what's already in the changelog — if a commit is already covered by an existing entry (even with different wording), skip it.
Step 4: Write Entries
Group by category (Features, Improvements, Bug Fixes, Performance). Adapt categories to the project's domain when appropriate, and factor in any optional additional context.
Writing rules:
- Active voice: "Create shareable links" not "Shareable links were added"
- Describe what users can do differently, not how the implementation works — even for technical projects. "Project setup is now smarter and faster" not "Adopted three-tier context model with signal-to-noise scoring"
- Bold the feature name: Feature name - description
- One line per entry
- Combine multiple commits for one feature into a single entry
Step 5: Update CHANGELOG.md
Add a new section at the top (after the header):
## Month Year
### Category
- **Feature name** - Brief description
---
Step 6: Verify
- Only user-facing changes included
- No technical jargon
- Consistent formatting with existing entries
- No duplicates with existing changelog content
Example transformation — feat(auth): add OAuth2 login with Google becomes **Google sign-in** - Sign in with your Google account for faster access.
Guidelines
- User perspective — ask "Would a user notice or care about this?"
- No duplicates — check existing entries before adding
- Combine related commits — multiple commits for one feature = one entry
- Positive framing — "Fixed X" is better than "X was broken"
Related Skills
Before: Use forge-address-pr-feedback to address reviewer feedback before merging.
Example Usage
/forge-update-changelog
/forge-update-changelog 2025-01-01
/forge-update-changelog 2025-01-01 -- emphasize user-visible setup workflow improvements