mirror of
https://github.com/garrytan/gstack.git
synced 2026-06-26 19:49:57 +02:00
Garry Tan
261d57a8e3
ship/SKILL.md drops 167KB → 68.7KB (~59% of the always-loaded skill) by moving
8 prose-heavy steps into ship/sections/*.md, read on demand:
tests, test-coverage, plan-completion, review-army, greptile, adversarial,
changelog, pr-body. Step 12's version logic now calls the tested
gstack-version-bump CLI instead of inline bash.
Claude-first (S2): {{SECTION:id}} emits a STOP-Read pointer on Claude (skeleton +
generated section files) and INLINES the content on every other host, so external
hosts keep the full monolith — verified factory at 162KB with no sections dir.
{{SECTION_INDEX:ship}} renders the situation→section table from the PASSIVE
manifest (CM2 / v2_PLAN.md:663); required-reads live only in test fixtures.
Multi-pass resolve expands inlined sections' own resolvers.
Parity: ship invariant flipped to sectioned (union content checks + maxSkeletonBytes
asserts the shrink). Carve-fallout fixed across gen-skill-docs/skill-validation/
golden/plan-completion/#1539/size-budget tests via skeleton+sections union reads.
Free suite green except the pre-existing investigate parity drift.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
<!-- AUTO-GENERATED from changelog.md.tmpl — do not edit directly -->
|
|
<!-- Regenerate: bun run gen:skill-docs -->
|
|
## Step 13: 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.
|
|
|
|
---
|