Cc changelog
Skill oliver-kriska/claude-elixir-phoenix/.claude/skills/cc-changelog
CONTRIBUTOR TOOL - Track CC changelog, extract new versions since last check, analyze impact on plugin (breaking changes, opportunities, deprecations). Run periodically or before releases. NOT part of the distributed plugin.From its SKILL.md
npx -y skills add oliver-kriska/claude-elixir-phoenix --skill cc-changelogAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- runs commandsInstructs the agent to run 4 commands, including `bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh"` and 3 more.
SKILL.md
3.4 KB, 777 tokens by cl100k_base, as published. Nobody here has run it
Claude Code Changelog Assistant
Tracks Claude Code releases against the plugin. Fetches the CC changelog, extracts entries newer than last check, and analyzes impact on plugin components (agents, skills, hooks, config).
Usage
/cc-changelog # Check for new CC versions, analyze impact
/cc-changelog --full # Re-analyze all versions (ignore last check)
/cc-changelog --set=2.1.85 # Reset last checked version (then re-run)
Execution Flow
Step 1: Fetch & Extract New Entries
bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh"
If output starts with STATUS: UP_TO_DATE → report "No new CC versions" and stop.
If STATUS: NEW_VERSIONS → continue with the changelog content below the header.
For --full: run bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh" --all
For --set=X: run bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh" --set=X, then re-run without flag.
Step 2: Analyze Impact
Read the new changelog entries. For EACH entry, classify into one of:
| Category | Meaning | Action |
|---|---|---|
| BREAKING | May break existing plugin functionality | Immediate fix required |
| OPPORTUNITY | New CC feature the plugin could use | Add to backlog/plan |
| RELEVANT FIX | CC fixed a bug we worked around | Check if workaround can be removed |
| DEPRECATION | CC removing something we use | Plan migration |
| INFO | Good to know, no action needed | Log in memory update |
Cross-reference against plugin components using rules in
${CLAUDE_SKILL_DIR}/references/analysis-rules.md.
Step 3: Generate Report
Output a structured report:
## CC Changelog Analysis: v{last_checked} → v{latest}
### BREAKING (action required)
- [version] description → **Impact**: which plugin file/component
**Fix**: specific action needed
### OPPORTUNITY (new features)
- [version] description → **Use case**: how plugin could benefit
**Files**: which plugin files to update
### RELEVANT FIX (workaround removal)
- [version] description → **Current workaround**: what we do now
**Action**: can we simplify?
### DEPRECATION (migration needed)
- [version] description → **We use this in**: file:line
**Migration**: what to change
### INFO (no action)
- [version] brief summary (collapsed)
Step 4: Update State
After user reviews the report, ask:
"Update last checked version to {latest}? This also updates the CC internals memory file. [Yes/No]"
If yes:
- Run
bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh" --set={latest} - Update memory file
reference_cc_source_internals.mdwith new findings - If BREAKING or DEPRECATION items found, offer to create a plan
Iron Laws
- ALWAYS fetch before analyzing — never analyze stale cache
- NEVER auto-update state — user must confirm after reviewing report
- ALWAYS cross-reference plugin files — don't just summarize, map to impact
- BREAKING changes are BLOCKERS — surface first, prominently
- Track the audit version — state file is the source of truth
What ships with it: 1 file
5.5 KB alongside SKILL.md
references/
- analysis-rules.md5.5 KB
Gives 0 of the 12 instructions most readme changelog skills give in 777 tokens
Counted across 446 of the 460 authors here whose files we hold, read 2026-09-06
- Follow Keep a Changelog formatin 24 of 446
- Collect commits since the last git tagin 15 of 446, across 13 files
- Omit empty sectionsin 14 of 446
- Put breaking changes first with migration stepsin 14 of 446
- Include migration guidance for breaking changesin 11 of 446, across 10 files
- Categorize commits by conventional commit prefixin 11 of 446
- Mark breaking changes prominentlyin 10 of 446
- Prepend the new entry to CHANGELOG.mdin 9 of 446
- Highlight breaking changes with migration notesin 8 of 446, across 7 files
- Classify changes into Keep a Changelog categoriesin 8 of 446, across 7 files
- Group related commits into single entriesin 8 of 446
- Write the changelog from commitsin 8 of 446
Said here and by no other author read
- Classify each new entry into one category
- Cross-reference entries against plugin components
- Stop if status is up to date
- Ask user to confirm before updating state
- Update the memory file with new findings
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.