cc-changelog
The cc-changelog skill monitors Claude Code releases and evaluates their impact on an Elixir Phoenix plugin by fetching the changelog, extracting new entries since the last check, and categorizing changes as breaking, opportunities, relevant fixes, deprecations, or informational items. Use this to stay informed about Claude Code updates that may require plugin modifications or offer new capabilities to adopt.
git clone --depth 1 https://github.com/oliver-kriska/claude-elixir-phoenix /tmp/cc-changelog && cp -r /tmp/cc-changelog/.claude/skills/cc-changelog ~/.claude/skills/cc-changelogSKILL.md
# 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
```text
/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
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:
```markdown
## 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:
1. Run `bash "${CLAUDE_PROJECT_DIR}/scripts/fetch-cc-changelog.sh" --set={latest}`
2. Update memory file `reference_cc_source_internals.md` with new findings
3. If BREAKING or DEPRECATION items found, offer to create a plan
## Iron Laws
1. **ALWAYS fetch before analyzing** — never analyze stale cache
2. **NEVER auto-update state** — user must confirm after reviewing report
3. **ALWAYS cross-reference plugin files** — don't just summarize, map to impact
4. **BREAKING changes are BLOCKERS** — surface first, prominently
5. **Track the audit version** — state file is the source of truthAsh Framework — resources, actions, policies, aggregates, calculations,
Compatibility alias for the Elixir/Phoenix plugin's LiveView assigns audit. Invoke explicitly with /lv:assigns.
Inspect LiveView socket assigns for memory bloat — missing temporary_assigns, unused assigns, unbounded lists needing streams, memory estimates. Use when LiveView memory grows or you need to add temporary_assigns.
Project health audit and health check — architecture, performance, tests, dependencies, code quality. Use when assessing overall project health, before releases, or after refactors.
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
Brainstorm Elixir/Phoenix features — explore ideas, compare approaches, gather requirements. Use when vague idea, not sure how to approach, or want to discuss before plan.
Interactive briefing of a plan file — explains reasoning, schema decisions, component choices. Use when developers need to understand a plan before approving.
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.