Walkthrough

Adds explicit-version support to /update-changelog (accepts semver with optional .rc.N/.beta.N), requires user confirmation when a suggested bump is ambiguous, automates branch/commit/push/PR for release/rc/beta modes, consolidates changelog blocks when collapsing prerelease sections, and adds CHANGELOG entry 16.4.0.rc.10.

Changes

Sequence Diagram(s)

sequenceDiagram
  participant User
  participant LocalRepo as Repo
  participant Rake
  participant GitRemote as Remote
  participant GitHub as PR

  User->>Repo: run /update-changelog [explicit-version?]
  alt explicit version provided
    Repo->>Rake: invoke with explicit version (stamp header from provided version)
    Rake-->>Repo: generate changelog diff, verify stamped header and links
  else mode-based or auto
    Repo->>Rake: invoke auto-compute mode
    Rake-->>Repo: compute suggested bump (may be ambiguous)
    Repo->>User: prompt to confirm or override bump (requires justification if ambiguous)
  end
  Repo->>Repo: update CHANGELOG and render consolidated Unreleased (merge identical headings)
  alt release/rc/beta mode (or mode stamping)
    Repo->>Repo: create branch, commit changelog + related files
    Repo->>GitRemote: push branch
    GitRemote->>GitHub: open PR with changelog diff
    GitHub-->>User: PR created (reminder: post-merge release steps)
  end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• fix: update CHANGELOG for 16.4.0.rc.9 and fix orphaned prerelease link cleanup #2596 — Touches react_on_rails/rakelib/update_changelog.rake, related prerelease collapsing/consolidation logic.
• Stamp 16.4.0.rc.7 changelog and collapse rc.6 #2579 — Related changes to prerelease merging behavior and changelog section handling.

Poem

🐰 I hopped through headers, stitched each line,
I stamped rc.10 and made it shine,
I nudged the branch, then gave a cheer,
A little PR appeared — hooray, my dear!
Carrots, tests, and changelog rhyme.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR stamps the 16.4.0.rc.10 version header in the CHANGELOG, adds the PR #2597 entry (clean stale webpack config on --rspack install) under #### Fixed, collapses the prior rc.9 section into rc.10 per prerelease conventions, and updates the version comparison links at the bottom of the file. The /update-changelog skill is also improved to auto-commit/push/PR after stamping and to ask for confirmation on ambiguous version bumps.

• Issue: Missing #### Pro heading — The second #### Pro section (which scoped the ##### Fixed Pro entries like streaming deadlock fixes, HTTPX error handling, etc.) was removed in this diff. These Pro-specific entries now appear as open-source entries, inconsistent with the changelog's own documentation that "Pro-specific changes appear under #### Pro sections."
• The /update-changelog skill improvements are well-structured and the automation of commit/push/PR creation is a useful workflow enhancement.

Confidence Score: 3/5

• Documentation-only PR that is safe to merge after restoring the missing #### Pro heading
• Score of 3 reflects a structural issue in the CHANGELOG: the #### Pro heading was accidentally removed, causing Pro-specific entries to lose their categorization. The skill file changes are clean. No code changes are involved.
• CHANGELOG.md — missing #### Pro heading before ##### Fixed on line 74

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Run /update-changelog rc"] --> B["Analyze commits & PRs since last tag"]
    B --> C["Add new entries under Unreleased"]
    C --> D["Collapse prior rc.9 section into rc.10"]
    D --> E["Stamp 16.4.0.rc.10 header with date"]
    E --> F["Update version comparison links"]
    F --> G["Auto-commit, push, open PR"]
    G --> H["User merges PR & runs rake release"]

_{Last reviewed commit: 596cc76}

Review: CHANGELOG + /update-changelog skill update

Documentation-only PR, no runtime impact. A few structural issues worth addressing before merging.

🔴 CHANGELOG structure: rc.9 section removed

The ### [16.4.0.rc.9] - 2026-03-12 header was deleted, which merges all rc.9 items directly into rc.10. As a result there is no way to tell which items were shipped in rc.9 vs. the new rc.10. The typical pattern for RC changelogs is to keep each version's items under its own dated header and only add the net-new work under the new version.

The intent was likely to stamp rc.10 on top of the existing [Unreleased] block, but the rc.9 header should have been preserved to separate the two versions.

🔴 Orphaned ##### Fixed section

By removing the #### Pro sub-heading (line 74 in the merged file), the ##### Fixed block that follows now has no #### Pro parent. In the rendered changelog it appears as a level-5 heading directly beneath a level-4 #### Fixed section — breaking the established #### Pro > ##### <type> hierarchy this file uses throughout.

🟡 Duplicate #### Fixed headings under rc.10

After the merge the rc.10 section contains two #### Fixed headings (lines 30 and 42). The second one was inherited from rc.9. These should either be consolidated, or (preferably) the rc.9 section header should be restored to keep the content separate.

🟡 Hardcoded personal branch prefix in skill instructions

.claude/commands/update-changelog.md now instructs Claude to create branches like `jg/changelog-16.4.0.rc.10` — the jg/ prefix is personal and would be wrong for any other contributor running the skill. A generic prefix (e.g. changelog/) or a dynamic one derived from the git user would be more appropriate.

✅ Positives

• Adding PR Fix #2549: clean stale webpack config on --rspack install #2597 entry and its Issue Clean up stale config/webpack/ files when installing with --rspack #2549 cross-link is correct.
• The clarification in step 5 (explicit confirmation on ambiguous bumps) is a good guardrail.
• Updating the [unreleased] compare link to point at 16.4.0.rc.10...master is correct.

Review Summary

Overall: Documentation-only PR, low risk. The CHANGELOG update and skill improvements are straightforward, but there are three issues worth addressing before merge.

Issues Found

1. Duplicate #### Fixed sections in CHANGELOG.md (bug)
When collapsing 16.4.0.rc.9 into 16.4.0.rc.10, the section header was removed but its content wasn't reorganized. The result is two #### Fixed headings inside the same [16.4.0.rc.10] release block — the PR 2477 fix entry ends up stranded in a second Fixed section after #### Improved. That entry should be merged into the first Fixed block. (Inline comment on line 42.)

2. Hardcoded personal branch prefix in skill docs
The new auto-commit step uses jg/changelog-... as the example branch name. This will confuse or mislead anyone who isn't Justin Gordon. Suggest using a generic prefix like update/changelog-.... (Inline comment on line 328.)

3. Explicit-version flow is roundabout
When the user passes an explicit version string, the instructions still tell Claude to run the rake task (which auto-computes) and then manually fix the result if it differs. Since the whole point of passing an explicit version is to skip auto-computation, the cleaner path is to insert the header and update the diff links directly. (Inline comment on line 308.)

Review Notes

Overall this is a clean documentation-only PR with two minor issues worth addressing.

CHANGELOG.md

The RC-collapse approach (merging rc.9 entries into rc.10 and pointing the diff link from v16.3.0) is consistent with the documented skill behaviour — no issues there.

One pre-existing structural artifact surfaced during the collapse: line 54 contains floating prose (Changes since the last non-beta release.) that sits between the #### Pro sub-section and the next #### Added heading. This wasn't introduced by this PR, but it's worth cleaning up in a follow-on since it breaks the visual hierarchy of the rc.10 section.

.claude/commands/update-changelog.md

Two issues called out inline:

1. Explicit version flow still runs the auto-compute rake task (lines 302–308) — runs the task then patches the result if it differs, which is the opposite of what "explicit version" implies. Suggested skipping the rake task and writing the header/links directly.

2. Hardcoded jg/ branch prefix (line 328) — will mislead any contributor other than Justin. Suggested changelog/ as a neutral convention.

Neither blocker; the CHANGELOG content itself looks correct.

Review of PR 2608 — Update CHANGELOG for 16.4.0.rc.10

Overall this is a clean documentation-only PR. Two minor issues in the skill doc and one structural issue in CHANGELOG.md worth addressing before merge.

CHANGELOG.md — duplicate Fixed sections within rc.10

The 16.4.0.rc.10 block currently has two separate #### Fixed headings (lines 30 and 42 of the post-merge file):

• Line 30: Fixed block with Ruby 3.4, install generator, server_render_js, rspack entries
• Line 37: Improved block
• Line 42: A second Fixed block with the bin/setup / pnpm entry (PR 2477)
• Line 46: Changed block

Having Fixed -> Improved -> Fixed within one version block is non-standard and will confuse readers scanning the changelog. The bin/setup entry should be merged up into the first Fixed block. Since that entry was reorganized as part of this PR's move away from rc.9, this is the right time to fold it in.

update-changelog.md — two nits (inline comments already filed)

1. Explicit-version path is fragile (line 308): Running bundle exec rake update_changelog[rc] and then manually patching the header if the auto-computed version differs from the requested one is error-prone. The diff links at the bottom of CHANGELOG.md are easy to get wrong in a manual fixup. Consider passing the explicit version directly to the rake task, or skipping rake altogether and doing a targeted string substitution for explicit versions.

2. Hardcoded branch name prefix (line 334): The example jg/changelog-16.4.0.rc.10 uses Justin's initials. When any other contributor or an unattended Claude run uses this command, it will produce branches with the wrong prefix. Use a generic template like changelog/16.4.0.rc.10 instead.

Review Summary

Overall this is a clean, low-risk PR — changelog stamping + tooling improvements. Three issues worth addressing:

Bug: stray marker text in CHANGELOG.md (line ~54)

Changes since the last non-beta release. still appears inside the [16.4.0.rc.10] section body. This is an internal processing marker that consolidate_changelog_blocks strips during a full prerelease collapse, but it was already present in the rc.9 section body and was carried forward when rc.9 was renamed/stamped as rc.10. It should be manually removed before merge — it will appear verbatim in the published changelog.

#### Added section sits outside #### Pro hierarchy

Immediately after the stray marker, there is an #### Added block (lines ~56–62) that contains Pro-specific features. Structurally these entries should either be under ##### Added inside #### Pro, or the #### Pro block should follow the top-level #### Added. The current layout makes the Pro entries look like OSS-level additions.

Inline comments posted

• .claude/commands/update-changelog.md line 328 — hardcoded jg/ branch prefix should be generic.
• update_changelog.rake line 274 — merged content separator (\n vs \n\n) for duplicate headings.
• update_changelog.rake line 300 — note on the subtle merge-order change (Unreleased blocks now prepended rather than appended).

Review: CHANGELOG restructuring for 16.4.0.rc.10

Overall this is a clean and well-organized consolidation — collapsing rc.9 into rc.10, converting #### Pro sub-sections to inline **[Pro]** tags, and adding PR 2597. The formatting is consistent and the context note added to 16.2.0 is a useful historical signpost.

Three issues found:

Review Notes

CHANGELOG.md — duplicate entries in 16.4.0.rc.9

The 16.4.0.rc.9 section has two #### Improved headings and two #### Changed headings:

• #### Improved appears twice: PR 2439 and PR 2571 are listed under the first occurrence (around lines 40-41) and again under the second (around lines 86-87). PR 2354 ("Smarter duplicate registration warnings") is only in the second block and should be the sole new entry there.
• #### Changed appears twice: PR 2482 is under the first heading, PR 2590 under the second. They should be consolidated under one heading.

The consolidate_changelog_blocks helper introduced in this PR would catch these on a future RC collapse, but 16.4.0.rc.9 is already a stamped section so it won't be collapsed again. These duplicates need a manual fix before tagging a stable release.

update_changelog.rake — two non-critical observations (not in the diff, FYI only)

1. Silent failure in update_changelog_links (around line 505): The function returns nil if it cannot find the [unreleased] compare link, but the call-site ignores the return value. A missing or malformed [unreleased] link causes the task to write the changelog without updating version diff links, with no warning. A simple warn on nil return would improve debuggability.

2. Hardcoded master branch (around lines 216 and 421): Both cleanup_collapsed_prerelease_links and update_changelog_links match ...master literally. Consistent with the existing CHANGELOG.md links, but a shared constant would make a future main migration a one-line change.

consolidate_changelog_blocks and deduplicate_block_entries — looks good

The new consolidation and deduplication logic is well-structured and thoroughly tested. The handling of #### Pro header-only blocks, emoji normalization in heading keys, and the pending-subheading accumulator for sub-sections are all correct and well-covered by the new specs.

Review posted inline. See discussion_r2937677113 for the main finding (spec ArgumentError). Summary: 3 issues found: (1) Critical - existing compute_auto_version spec tests use the old 4-arg signature that was removed in this PR and will raise ArgumentError; (2) Dead code - prerelease_indices_from_changelog is defined but no longer called; (3) Silent failure - update_changelog_links returns nil silently when compare links pattern not found.

Review: PR #2608 — Update CHANGELOG for 16.4.0.rc.10

Overall this is well-executed. The changelog entries are complete and correctly formatted, the #### Pro section refactoring is consistent across AGENTS.md / CLAUDE.md / changelog-guidelines.md, and the rake file additions are well-tested (the spec covers heading consolidation, deduplication, Pro sub-section ordering, and emoji-variant normalization).

Main finding: dead code in update_changelog.rake

prerelease_indices_from_changelog (line 126) is now dead code. It was removed from compute_auto_version by this PR (see inline comment on line 412) and has no remaining callers. Leaving it in place creates confusion — readers may wonder if changelog headers are still consulted for RC index computation. The function should be deleted.

Pre-existing issues (out of scope for this PR, but worth tracking)

Two pre-existing patterns in the rake file that could trip up future contributors:

1. rescue SystemExit in parse_release_tag_to_version (line 45-46): normalize_version_string calls abort to signal invalid input, and parse_release_tag_to_version rescues the resulting SystemExit to return nil. Using exception-for-control-flow via abort/SystemExit is surprising and makes the nil-return path easy to miss. A simple refactor would extract a valid_version_string? predicate and have the tag parser call that directly.

2. Hardcoded master branch in update_changelog_links and cleanup_collapsed_prerelease_links: the compare-link pattern and replacement both hardcode ...master. This is consistent with the current CHANGELOG.md content, so no immediate breakage, but worth abstracting into a constant if branch naming ever changes.

Minor positives

• The explicit-version mode doc and the corresponding rake task path are nicely symmetric.
• Auto-commit/push/PR in Step 5 is a good workflow improvement; the failure fallback note is appropriately defensive.
• The test for fetch_git_tags! using a real bare git repo (rather than mocking Open3) is the right call — it validates the actual shell commands.