chatandbuild/Changelog Automation
skills/changelog-automation/SKILL.md
Use this skill when generating or maintaining release changelogs from merged work, including version scope, grouped changes, breaking-change notes, formatting consistency, and verification checks.
$ install --global
skillsauthnpx skillsauth add chatandbuild/skills-repo Changelog AutomationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 14, 2026, 3:23 AM151.0s2 files scanned
SKILL.md
- id:
- changelog-automation
- name:
- Changelog Automation
- description:
- Use this skill when generating or maintaining release changelogs from merged work, including version scope, grouped changes, breaking-change notes, formatting consistency, and verification checks.
- category:
- DevOps
Changelog Automation
Automate changelog creation while keeping release notes accurate and auditable.
When to Use
- You need consistent release notes across frequent deployments.
- You want changelog entries grouped by meaningful change categories.
- You need a review step to prevent misleading release notes.
Workflow
-
Define release scope. Use git-log-based range detection:
git log <last-tag>..HEAD --onelineorgit log --since="YYYY-MM-DD". Prefer tag-to-HEAD for versioned releases. For date-based ranges, ensure the range is inclusive and timezone-consistent. -
Collect and classify changes. Parse conventional commits (
feat:,fix:,docs:,refactor:,perf:,chore:,BREAKING CHANGE:) from commit messages. When PRs are the source of truth, use PR labels (e.g.,type:feature,type:fix,type:breaking) for grouping. Prefer PR metadata over raw commits when squash merges flatten history. -
Draft changelog sections. Use impact-focused language: describe what changed and why it matters to users, not implementation details. Group entries under standard headers: Added, Changed, Fixed, Deprecated, Removed, Security, Breaking Changes.
-
Handle breaking changes. Every breaking change must appear under a dedicated "Breaking Changes" section with a clear migration note: what was removed or changed, what to do instead, and any required code updates.
-
Apply semantic version bumping rules. Map change types to version bumps: breaking -> major; new features -> minor; fixes and patches -> patch. Validate that the proposed version matches the collected change set.
-
Run verification. Ensure no duplicate entries, no empty sections, correct date and version formatting, and that all referenced PRs/commits exist. Flag any entries that look auto-generated but lack human review.
Commit Message and PR Label Conventions
Conventional Commits (for commit-based changelogs):
feat(scope): description-> Addedfix(scope): description-> Fixeddocs(scope): description-> Documentationrefactor(scope): description-> Changedperf(scope): description-> Performancechore(scope): description-> omit or Chore- Footer:
BREAKING CHANGE: description-> Breaking Changes
PR labels (for PR-based changelogs):
changelog:added,type:feature-> Addedchangelog:fixed,type:bugfix-> Fixedchangelog:changed,type:refactor-> Changedchangelog:breaking,type:breaking-> Breaking Changeschangelog:skip-> exclude from changelog
Standardize on one scheme per repo and document it in CONTRIBUTING.md.
Output Format
## [X.Y.Z] - YYYY-MM-DD
### Added
- Short, user-facing description of the change. (#PR or commit hash)
### Changed
- Description of behavioral or API changes.
### Fixed
- Bug fix description with impact.
### Deprecated
- What is deprecated and when it will be removed.
### Removed
- What was removed and why.
### Security
- Security-related changes.
### Breaking Changes
- **Component/API name:** What broke. Migration: what to do instead. (#PR)
### Migration Notes
- Step-by-step upgrade instructions if non-trivial.
### Contributors
- @username (contributions)
Include contributor attribution from PR authors or commit authors when available. Link PR numbers and commit hashes for traceability.
Common Pitfalls
-
Mixing human-written and auto-generated entries. Avoid editing the same changelog section by hand and by automation; pick one source of truth. If humans add entries, ensure automation does not overwrite them or duplicate.
-
Missing breaking change callouts. Breaking changes buried in "Changed" or omitted entirely cause upgrade surprises. Always surface them in a dedicated section with migration guidance.
-
Stale changelogs from squash merges. Squash merges replace branch commits with a single merge commit. If changelog generation reads commits, it may miss individual PRs. Prefer PR-based collection when using squash merge.
-
Vague or implementation-heavy entries. Entries like "Refactored X" or "Updated dependencies" are unhelpful. Write for end users: "Improved login performance by 40%" or "Upgraded React to v18 for concurrent features."
-
Inconsistent version or date format. Stick to one format (e.g., [SemVer] - ISO date) and apply it everywhere.
Constraints
- Do not invent changelog entries; every entry must trace to a real commit or PR.
- Do not remove or alter human-written changelog content without explicit instruction.
- Prefer conventional commits or documented PR labels; avoid ad-hoc parsing heuristics.
- Always include a verification step before publishing.
- Breaking changes must have migration notes; do not leave them unexplained.
- Keep entries concise (one to two sentences); link to PRs or docs for detail.
Related Skills
chatandbuild/yeet
tools
VerifiedTrustedCommunity
Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/xlsx
development
VerifiedTrustedCommunity
Use this skill any time a spreadsheet file is the primary input or output. This means any task where the user wants to: open, read, edit, or fix an existing .xlsx, .xlsm, .csv, or .tsv file (e.g., adding columns, computing formulas, formatting, charting, cleaning messy data); create a new spreadsheet from scratch or from other data sources; or convert between tabular file formats. Trigger especially when the user references a spreadsheet file by name or path — even casually (like "the xlsx in my downloads") — and wants something done to it or produced from it. Also trigger for cleaning or restructuring messy tabular data files (malformed rows, misplaced headers, junk data) into proper spreadsheets. The deliverable must be a spreadsheet file. Do NOT trigger when the primary deliverable is a Word document, HTML report, standalone Python script, database pipeline, or Google Sheets API integration, even if tabular data is involved.
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/Workout Logger
development
VerifiedTrustedCommunity
Use this skill when turning messy workout information into clear logs, comparing user-provided sessions, surfacing trends or likely PRs, and suggesting realistic next-session steps.
1SKILL.mdUpdated Jul 22, 2026
chatandbuild/webapp-testing
tools
VerifiedTrustedCommunity
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
1SKILL.mdUpdated Jul 22, 2026