gstack/ship/sections/changelog.md at c91154655f1beadad2aaa7033cd61e34ce4dba01

mirror of https://github.com/garrytan/gstack.git synced 2026-06-19 08:10:08 +02:00

Files

T

Garry Tan 261d57a8e3 refactor(ship): carve into skeleton + on-demand sections (Claude) (T9)

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>

2026-05-30 10:11:00 -07:00

1.8 KiB

Raw Blame History

Step 13: CHANGELOG (auto-generate)

Read CHANGELOG.md header to know the format.
First, enumerate every commit on the branch:
```
git log <base>..HEAD --oneline
```
Copy the full list. Count the commits. You will use this as a checklist.
Read the full diff to understand what each commit actually changed:
```
git diff <base>...HEAD
```
Group commits by theme before writing anything. Common themes:
- New features / capabilities
- Performance improvements
- Bug fixes
- Dead code removal / cleanup
- Infrastructure / tooling / tests
- Refactoring
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.
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.

1.8 KiB Raw Blame History

Step 13: CHANGELOG (auto-generate)

1.8 KiB

Raw Blame History