mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-19 19:02:29 +08:00
feat: extract CHANGELOG_WORKFLOW resolver from /ship
Move changelog generation logic into a reusable resolver. The resolver
is changelog-only (no version bump per Codex review recommendation).
Adds voice rules inline. /ship Step 5 now uses {{CHANGELOG_WORKFLOW}}.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -12,7 +12,7 @@ import { generateCommandReference, generateSnapshotFlags, generateBrowseSetup }
|
|||||||
import { generateDesignMethodology, generateDesignHardRules, generateDesignOutsideVoices, generateDesignReviewLite, generateDesignSketch, generateDesignSetup, generateDesignMockup, generateDesignShotgunLoop } from './design';
|
import { generateDesignMethodology, generateDesignHardRules, generateDesignOutsideVoices, generateDesignReviewLite, generateDesignSketch, generateDesignSetup, generateDesignMockup, generateDesignShotgunLoop } from './design';
|
||||||
import { generateTestBootstrap, generateTestCoverageAuditPlan, generateTestCoverageAuditShip, generateTestCoverageAuditReview } from './testing';
|
import { generateTestBootstrap, generateTestCoverageAuditPlan, generateTestCoverageAuditShip, generateTestCoverageAuditReview } from './testing';
|
||||||
import { generateReviewDashboard, generatePlanFileReviewReport, generateSpecReviewLoop, generateBenefitsFrom, generateCodexSecondOpinion, generateAdversarialStep, generateCodexPlanReview, generatePlanCompletionAuditShip, generatePlanCompletionAuditReview, generatePlanVerificationExec } from './review';
|
import { generateReviewDashboard, generatePlanFileReviewReport, generateSpecReviewLoop, generateBenefitsFrom, generateCodexSecondOpinion, generateAdversarialStep, generateCodexPlanReview, generatePlanCompletionAuditShip, generatePlanCompletionAuditReview, generatePlanVerificationExec } from './review';
|
||||||
import { generateSlugEval, generateSlugSetup, generateBaseBranchDetect, generateDeployBootstrap, generateQAMethodology, generateCoAuthorTrailer } from './utility';
|
import { generateSlugEval, generateSlugSetup, generateBaseBranchDetect, generateDeployBootstrap, generateQAMethodology, generateCoAuthorTrailer, generateChangelogWorkflow } from './utility';
|
||||||
import { generateLearningsSearch, generateLearningsLog } from './learnings';
|
import { generateLearningsSearch, generateLearningsLog } from './learnings';
|
||||||
import { generateConfidenceCalibration } from './confidence';
|
import { generateConfidenceCalibration } from './confidence';
|
||||||
import { generateInvokeSkill } from './composition';
|
import { generateInvokeSkill } from './composition';
|
||||||
@@ -55,4 +55,5 @@ export const RESOLVERS: Record<string, ResolverFn> = {
|
|||||||
LEARNINGS_LOG: generateLearningsLog,
|
LEARNINGS_LOG: generateLearningsLog,
|
||||||
CONFIDENCE_CALIBRATION: generateConfidenceCalibration,
|
CONFIDENCE_CALIBRATION: generateConfidenceCalibration,
|
||||||
INVOKE_SKILL: generateInvokeSkill,
|
INVOKE_SKILL: generateInvokeSkill,
|
||||||
|
CHANGELOG_WORKFLOW: generateChangelogWorkflow,
|
||||||
};
|
};
|
||||||
|
|||||||
@@ -375,3 +375,47 @@ export function generateCoAuthorTrailer(ctx: TemplateContext): string {
|
|||||||
}
|
}
|
||||||
return 'Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>';
|
return 'Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>';
|
||||||
}
|
}
|
||||||
|
|
||||||
|
export function generateChangelogWorkflow(_ctx: TemplateContext): string {
|
||||||
|
return `## CHANGELOG (auto-generate)
|
||||||
|
|
||||||
|
1. Read \`CHANGELOG.md\` header to know the format.
|
||||||
|
|
||||||
|
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
|
||||||
|
- \`### Changed\` — changes to existing functionality
|
||||||
|
- \`### Fixed\` — bug fixes
|
||||||
|
- \`### Removed\` — removed features
|
||||||
|
- Write concise, descriptive bullet points
|
||||||
|
- Insert after the file header (line 5), dated today
|
||||||
|
- Format: \`## [X.Y.Z.W] - YYYY-MM-DD\`
|
||||||
|
- **Voice:** Lead with what the user can now **do** that they couldn't before. Use plain language, not implementation details. Never mention TODOS.md, internal tracking, or contributor-facing details.
|
||||||
|
|
||||||
|
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.`;
|
||||||
|
}
|
||||||
|
|||||||
@@ -1714,7 +1714,7 @@ already knows. A good test: would this insight save time in a future session? If
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Step 5: CHANGELOG (auto-generate)
|
## CHANGELOG (auto-generate)
|
||||||
|
|
||||||
1. Read `CHANGELOG.md` header to know the format.
|
1. Read `CHANGELOG.md` header to know the format.
|
||||||
|
|
||||||
@@ -1747,6 +1747,7 @@ already knows. A good test: would this insight save time in a future session? If
|
|||||||
- Write concise, descriptive bullet points
|
- Write concise, descriptive bullet points
|
||||||
- Insert after the file header (line 5), dated today
|
- Insert after the file header (line 5), dated today
|
||||||
- Format: `## [X.Y.Z.W] - YYYY-MM-DD`
|
- Format: `## [X.Y.Z.W] - YYYY-MM-DD`
|
||||||
|
- **Voice:** Lead with what the user can now **do** that they couldn't before. Use plain language, not implementation details. Never mention TODOS.md, internal tracking, or contributor-facing details.
|
||||||
|
|
||||||
6. **Cross-check:** Compare your CHANGELOG entry against the commit list from step 2.
|
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,
|
Every commit must map to at least one bullet point. If any commit is unrepresented,
|
||||||
|
|||||||
@@ -342,46 +342,7 @@ For each classified comment:
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Step 5: CHANGELOG (auto-generate)
|
{{CHANGELOG_WORKFLOW}}
|
||||||
|
|
||||||
1. Read `CHANGELOG.md` header to know the format.
|
|
||||||
|
|
||||||
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
|
|
||||||
- `### Changed` — changes to existing functionality
|
|
||||||
- `### Fixed` — bug fixes
|
|
||||||
- `### Removed` — removed features
|
|
||||||
- Write concise, descriptive bullet points
|
|
||||||
- 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.
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user