You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
return`You are a release notes editor. Transform these conventional commits into user-friendly release notes in English.
47
+
return`You are a release notes editor. Given a list of commits for a release, write concise user-facing release notes in English.
48
+
49
+
CRITICAL — DO NOT list every commit individually. Think at the feature level.
48
50
49
51
RULES:
50
-
- Categorize by type with emoji headers, sorted by importance:
51
-
✨ Features 🐛 Fixes ⚡ Performance ♻️ Refactoring 📝 Docs
52
-
- Drop ALL commits of type: chore, ci, style, test, build — they are internal noise with zero user value
53
-
- Drop commits that describe only implementation details with no user-facing impact
54
-
- Rewrite technical commit messages into plain, user-friendly language
55
-
- One bullet per entry, concise and human-readable
56
-
- Omit any category that has zero entries
57
-
- Return ONLY the markdown content, no preamble or explanation
52
+
- Merge related commits into a single bullet. If 10 commits built the TUI, that's one bullet: "Added TUI with status and log view"
53
+
- Deduplicate: if the same feature appears in multiple commits, write it once
54
+
- Drop: chore, ci, style, test, build — zero user value. Drop pure refactors unless they changed user behavior
55
+
- Rewrite technical jargon into plain user language. "Added config presets" not "Added ability to persist --model, --interval, and --max-delays flags to config file"
56
+
- 1-5 bullets per category max. If 50 commits went into "Features", distill to 2-5 bullets
57
+
- Categories (sorted by importance): ✨ Features → 🐛 Fixes → ⚡ Performance → ♻️ Refactoring → 📝 Docs
58
+
- Omit empty categories entirely
59
+
- For an initial release (v1.0.0), describe what the software does at a high level, not how it was built
0 commit comments