Improve update-changelog command with better git workflow (#1961)

## Summary

Ports enhancements from Shakapacker PR #824 to improve the
`/update-changelog` slash command:

- **Explicit git fetch step**: Always fetch `origin/master` first to
ensure latest commits are available
- **Consistent origin/master usage**: Use `origin/master` instead of
local `master` throughout to avoid missing recently merged PRs
- **Automatic PR extraction**: Use grep to extract ALL PR numbers from
commit history automatically
- **PR existence checking**: Check if PRs are already documented before
adding duplicates
- **Version links documentation**: Add detailed instructions for
managing version comparison links
- **Simplified linting**: Use just `yarn lint` instead of multiple
commands
- **Better change identification**: Provide keyword hints for
identifying user-visible changes

## Test plan

- [x] Review the updated command documentation
- [x] Verify formatting with Prettier
- [x] Confirm pre-commit hooks pass
- [ ] Test the command with actual changelog updates

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- Reviewable:start -->
- - -
This change is [<img src="https://reviewable.io/review_button.svg"
height="34" align="absmiddle"
alt="Reviewable"/>](https://reviewable.io/reviews/shakacode/react_on_rails/1961)
<!-- Reviewable:end -->

Co-authored-by: Claude <[email protected]>

Author: justin808

.claude/commands/update-changelog.md

@@ -95,60 +95,86 @@ This will:
 - Add headers for the new version
 - Update version diff links at the bottom of the file
 
+### Version Links
+
+After adding an entry to the `## [Unreleased]` section, ensure the version diff links at the bottom of the file are correct.
+
+The format at the bottom should be:
+
+```markdown
+[Unreleased]: https://github.com/shakacode/react_on_rails/compare/v16.0.0...master
+[v16.0.0]: https://github.com/shakacode/react_on_rails/compare/v15.0.0...v16.0.0
+```
+
+When a new version is released:
+
+1. Change `[Unreleased]` heading to `## [vX.Y.Z] - Month Day, Year`
+2. Add a new `## [Unreleased]` section at the top
+3. Update the `[Unreleased]` link to compare from the new version
+4. Add a new version link for the released version
+
 ## Process
 
 ### For Regular Changelog Updates
 
-1. **Determine the correct version tag to compare against**:
+1. **ALWAYS fetch latest changes first**:
+
+   - **CRITICAL**: Run `git fetch origin master` to ensure you have the latest commits
+   - The workspace may be behind origin/master, causing you to miss recently merged PRs
+   - After fetching, use `origin/master` for all comparisons, NOT local `master` branch
+
+2. **Determine the correct version tag to compare against**:
 
    - First, check the tag dates: `git log --tags --simplify-by-decoration --pretty="format:%ai %d" | head -10`
    - Find the latest version tag and its date
-   - Compare main branch date to the tag date
-   - If the tag is NEWER than main, it means main needs to be updated to include the tag's commits
+   - Compare origin/master branch date to the tag date
+   - If the tag is NEWER than origin/master, it means the branch needs to be updated to include the tag's commits
    - **CRITICAL**: Always use `git log TAG..BRANCH` to find commits that are in the tag but not in the branch, as the tag may be ahead
 
-2. **Check commits and version boundaries**:
+3. **Check commits and version boundaries**:
 
-   - Run `git log --oneline LAST_TAG..master` to see commits since the last release
-   - Also check `git log --oneline master..LAST_TAG` to see if the tag is ahead of master
+   - **IMPORTANT**: Use `origin/master` in all commands below, not local `master`
+   - Run `git log --oneline LAST_TAG..origin/master` to see commits since the last release
+   - Also check `git log --oneline origin/master..LAST_TAG` to see if the tag is ahead of origin/master
    - If the tag is ahead, entries in "Unreleased" section may actually belong to that tagged version
-   - Identify which commits contain user-visible changes
-   - Extract PR numbers and author information from commit messages
-   - **Never ask the user for PR details** - get them from the git history
+   - **Extract ALL PR numbers** from commit messages using grep: `git log --oneline LAST_TAG..origin/master | grep -oE "#[0-9]+" | sort -u`
+   - For each PR number found, check if it's already in CHANGELOG.md using: `grep "PR XXX" CHANGELOG.md` (note: no hash in search since React on Rails uses no hash)
+   - Identify which commits contain user-visible changes (look for keywords like "Fix", "Add", "Feature", "Bug", etc.)
+   - Extract author information from commit messages
+   - **Never ask the user for PR details** - get them from the git history or use WebFetch on the PR URL
 
-3. **Validate** that changes are user-visible (per the criteria above). If not user-visible, skip those commits.
+4. **Validate** that changes are user-visible (per the criteria above). If not user-visible, skip those commits.
 
-4. **Read the current CHANGELOG.md** to understand the existing structure and formatting.
+5. **Read the current CHANGELOG.md** to understand the existing structure and formatting.
 
-5. **Determine where entries should go**:
+6. **Determine where entries should go**:
 
-   - If the latest version tag is NEWER than master branch, move entries from "Unreleased" to that version section
-   - If master is ahead of the latest tag, add new entries to "Unreleased"
+   - If the latest version tag is NEWER than origin/master branch, move entries from "Unreleased" to that version section
+   - If origin/master is ahead of the latest tag, add new entries to "Unreleased"
    - Always verify the version date in CHANGELOG.md matches the actual tag date
 
-6. **Add or move entries** to the appropriate section under appropriate category headings.
+7. **Add or move entries** to the appropriate section under appropriate category headings.
 
    - **CRITICAL**: When moving entries from "Unreleased" to a version section, merge them with existing entries under the same category heading
    - **NEVER create duplicate section headings** (e.g., don't create two "### Fixed" sections)
    - If the version section already has a category heading (e.g., "### Fixed"), add the moved entries to that existing section
    - Maintain the category order as defined above
 
-7. **Verify formatting**:
+8. **Verify formatting**:
 
    - Bold description with period
    - Proper PR link (NO hash symbol)
    - Proper author link
    - Consistent with existing entries
    - File ends with a newline character
 
-8. **Run linting** after making changes:
+9. **Run linting** after making changes:
 
    ```bash
-   bundle exec rubocop
-   yarn run lint
+   yarn lint
    ```
 
-9. **Show the user** the added or moved entries and explain what was done.
+10. **Show the user** the added or moved entries and explain what was done.
 
 ### For Beta to Non-Beta Version Release