CalvinBackup/gstack
1
0
Fork 0
mirror of https://github.com/garrytan/gstack.git synced 2026-05-01 11:17:50 +02:00
Code Issues Packages Projects Releases Wiki Activity

fix: /ship CHANGELOG and PR body now cover all branch commits (v0.12.4.0) (#535)

Browse Source 
* fix: /ship CHANGELOG and PR body now cover all branch commits

Step 5 (CHANGELOG generation) restructured to force explicit commit
enumeration, theme grouping, and cross-check before writing. Step 8
(PR body) changed from "bullet points from CHANGELOG" to commit-by-commit
coverage with logical sections. Fixes recency bias that dropped early
commits on long branches.

* chore: bump version and changelog (v0.12.3.0)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Garry Tan
2026-03-26 17:56:32 -06:00
committed by GitHub
parent 25e971bc5e
commit de20228c2c
5 changed files with 84 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ship/SKILL.md
+31 -5
View File
@@ -1590,10 +1590,26 @@ High-confidence findings (agreed on by multiple sources) should be prioritized f
1. Read `CHANGELOG.md` header to know the format.
2. Auto-generate the entry from **ALL commits on the branch** (not just recent ones):
- Use `git log <base>..HEAD --oneline` to see every commit being shipped
- Use `git diff <base>...HEAD` to see the full diff against the base branch
- The CHANGELOG entry must be comprehensive of ALL changes going into the PR
2. **First, enumerate every commit on the branch:**
```bash
git log <base>..HEAD --oneline
```
Copy the full list. Count the commits. You will use this as a checklist.
3. **Read the full diff** to understand what each commit actually changed:
```bash
git diff <base>...HEAD
```
4. **Group commits by theme** before writing anything. Common themes:
- New features / capabilities
- Performance improvements
- Bug fixes
- Dead code removal / cleanup
- Infrastructure / tooling / tests
- Refactoring
5. **Write the CHANGELOG entry** covering ALL groups:
- If existing CHANGELOG entries on the branch already cover some commits, replace them with one unified entry for the new version
- Categorize changes into applicable sections:
- `### Added` — new features
@@ -1604,6 +1620,11 @@ High-confidence findings (agreed on by multiple sources) should be prioritized f
- Insert after the file header (line 5), dated today
- Format: `## [X.Y.Z.W] - YYYY-MM-DD`
6. **Cross-check:** Compare your CHANGELOG entry against the commit list from step 2.
Every commit must map to at least one bullet point. If any commit is unrepresented,
add it now. If the branch has N commits spanning K themes, the CHANGELOG must
reflect all K themes.
**Do NOT ask the user to describe changes.** Infer from the diff and commit history.
---
@@ -1741,7 +1762,12 @@ The PR/MR body should contain these sections:
```
## Summary
<bullet points from CHANGELOG>
<Summarize ALL changes being shipped. Run `git log <base>..HEAD --oneline` to enumerate
every commit. Exclude the VERSION/CHANGELOG metadata commit (that's this PR's bookkeeping,
not a substantive change). Group the remaining commits into logical sections (e.g.,
"**Performance**", "**Dead Code Removal**", "**Infrastructure**"). Every substantive commit
must appear in at least one section. If a commit's work isn't reflected in the summary,
you missed it.>
## Test Coverage
<coverage diagram from Step 3.4, or "All new code paths have test coverage.">
ship/SKILL.md.tmpl
+31 -5
View File
@@ -339,10 +339,26 @@ For each classified comment:
1. Read `CHANGELOG.md` header to know the format.
2. Auto-generate the entry from **ALL commits on the branch** (not just recent ones):
- Use `git log <base>..HEAD --oneline` to see every commit being shipped
- Use `git diff <base>...HEAD` to see the full diff against the base branch
- The CHANGELOG entry must be comprehensive of ALL changes going into the PR
2. **First, enumerate every commit on the branch:**
```bash
git log <base>..HEAD --oneline
```
Copy the full list. Count the commits. You will use this as a checklist.
3. **Read the full diff** to understand what each commit actually changed:
```bash
git diff <base>...HEAD
```
4. **Group commits by theme** before writing anything. Common themes:
- New features / capabilities
- Performance improvements
- Bug fixes
- Dead code removal / cleanup
- Infrastructure / tooling / tests
- Refactoring
5. **Write the CHANGELOG entry** covering ALL groups:
- If existing CHANGELOG entries on the branch already cover some commits, replace them with one unified entry for the new version
- Categorize changes into applicable sections:
- `### Added` — new features
@@ -353,6 +369,11 @@ For each classified comment:
- Insert after the file header (line 5), dated today
- Format: `## [X.Y.Z.W] - YYYY-MM-DD`
6. **Cross-check:** Compare your CHANGELOG entry against the commit list from step 2.
Every commit must map to at least one bullet point. If any commit is unrepresented,
add it now. If the branch has N commits spanning K themes, the CHANGELOG must
reflect all K themes.
**Do NOT ask the user to describe changes.** Infer from the diff and commit history.
---
@@ -490,7 +511,12 @@ The PR/MR body should contain these sections:
```
## Summary
<bullet points from CHANGELOG>
<Summarize ALL changes being shipped. Run `git log <base>..HEAD --oneline` to enumerate
every commit. Exclude the VERSION/CHANGELOG metadata commit (that's this PR's bookkeeping,
not a substantive change). Group the remaining commits into logical sections (e.g.,
"**Performance**", "**Dead Code Removal**", "**Infrastructure**"). Every substantive commit
must appear in at least one section. If a commit's work isn't reflected in the summary,
you missed it.>
## Test Coverage
<coverage diagram from Step 3.4, or "All new code paths have test coverage.">