changelog-rules
installsforks
How to install changelog-rules?
tobihagemann/turbo/changelog-rules
$npx -y skills add tobihagemann/turbo --skill changelog-rulesShared changelog conventions and formatting rules referenced by /create-changelog and /update-changelog. Not typically invoked directly.
SKILL.md
| 1 | # Changelog Rules |
| 2 | |
| 3 | The changelog is kept in `CHANGELOG.md` at the project root. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and projects using these conventions adhere to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). |
| 4 | |
| 5 | ## File Structure |
| 6 | |
| 7 | ```markdown |
| 8 | # Changelog |
| 9 | |
| 10 | All notable changes to this project will be documented in this file. |
| 11 | |
| 12 | The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). |
| 13 | |
| 14 | ## [Unreleased] |
| 15 | |
| 16 | ## [1.2.0] - 2024-03-15 |
| 17 | |
| 18 | ### Added |
| 19 | |
| 20 | - Add dark mode support ([#38](https://github.com/owner/repo/issues/38), [#42](https://github.com/owner/repo/pull/42)) |
| 21 | |
| 22 | ### Fixed |
| 23 | |
| 24 | - Fix crash on startup ([#40](https://github.com/owner/repo/issues/40), [#43](https://github.com/owner/repo/pull/43)) |
| 25 | |
| 26 | [Unreleased]: https://github.com/<owner>/<repo>/compare/v1.2.0...HEAD |
| 27 | [1.2.0]: https://github.com/<owner>/<repo>/compare/v1.1.0...v1.2.0 |
| 28 | [1.1.0]: https://github.com/<owner>/<repo>/releases/tag/v1.1.0 |
| 29 | ``` |
| 30 | |
| 31 | ## Changelog-Worthiness |
| 32 | |
| 33 | Not every change belongs in a changelog. Changelogs are for humans, not machines. |
| 34 | |
| 35 | **Skip** changes that are purely internal: |
| 36 | |
| 37 | - Refactoring with no user-facing impact |
| 38 | - Code formatting, linting, whitespace |
| 39 | - Test additions or modifications (unless they indicate a fixed bug) |
| 40 | - CI/CD configuration |
| 41 | - Developer tooling (linters, editor config) |
| 42 | - Documentation updates (README, comments, docstrings) |
| 43 | - Dependency bumps with no behavior change |
| 44 | |
| 45 | **Include** changes that affect users: |
| 46 | |
| 47 | - New features or capabilities |
| 48 | - Changes to existing behavior |
| 49 | - Deprecated or removed functionality |
| 50 | - Bug fixes |
| 51 | - Security patches |
| 52 | |
| 53 | ## Entry Format |
| 54 | |
| 55 | - Imperative present tense without trailing periods (e.g., "Add dark mode support") |
| 56 | - One bullet point per distinct change |
| 57 | - Concise but complete. Include enough context that users understand the impact. |
| 58 | |
| 59 | ### User-Centric Writing |
| 60 | |
| 61 | Entries describe what changed **for the user**. Focus on outcomes and impact. |
| 62 | |
| 63 | - Lead with a user-visible verb: "Add", "Fix", "Improve", "Allow", "Prevent", "Show", "Check". Avoid developer-centric verbs like "Enforce", "Implement", "Refactor", "Handle", "Register". |
| 64 | - Describe the experience, not the mechanism. |
| 65 | - When a change prevents a problem or protects the user, say what it does for them. |
| 66 | |
| 67 | ### Net Delta from the Last Release |
| 68 | |
| 69 | Entries describe the change relative to the last released version. |
| 70 | |
| 71 | - Watch for entries that only make sense against an unreleased build, like "no longer does X" or "removed the Y glitch" where X or Y never shipped. |
| 72 | - When finalizing a release, review every entry and rewrite or collapse anything a user of the previous release would not observe. |
| 73 | - Keep one entry per net user-visible change. |
| 74 | |
| 75 | ## PR and Issue References |
| 76 | |
| 77 | Reference both the PR and any associated GitHub issue in each entry using inline parenthetical format with linked numbers in ascending order. |
| 78 | |
| 79 | ```markdown |
| 80 | - Add dark mode support ([#38](https://github.com/owner/repo/issues/38), [#42](https://github.com/owner/repo/pull/42)) |
| 81 | ``` |
| 82 | |
| 83 | To discover associated issues for a PR, run: |
| 84 | |
| 85 | ```bash |
| 86 | gh pr view <number> --json closingIssuesReferences --jq '.closingIssuesReferences[].number' |
| 87 | ``` |
| 88 | |
| 89 | - If there is no associated issue, reference only the PR |
| 90 | - If there is no PR (e.g., backfilling from git tags), omit references |
| 91 | |
| 92 | ## Change Types |
| 93 | |
| 94 | Standard types in this order when present: Added, Changed, Deprecated, Removed, Fixed, Security. Omit empty sections. |
| 95 | |
| 96 | ## Section Format |
| 97 | |
| 98 | - Unreleased section always present at the top |
| 99 | - ISO 8601 dates (`YYYY-MM-DD`) |
| 100 | - Reverse chronological order (newest first) |
| 101 | - Blank line between each section header and its content |
| 102 | - Version comparison links at the bottom, derived from the repository's remote URL |
| 103 | - Detect whether the project uses `v`-prefixed tags (e.g., `v1.0.0`) or bare tags (e.g., `1.0.0`) and match that convention in comparison links |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
