cc-changelog

$npx mdskill add oliver-kriska/claude-elixir-phoenix/cc-changelog

Tracks Claude Code releases and analyzes impact on plugin components.

  • Fetches new changelog entries since last check to identify relevant updates.
  • Depends on a bash script to fetch changelog data from Claude Code releases.
  • Classifies each new version as breaking, opportunity, or deprecation based on content.
  • Outputs a structured analysis of changes affecting agents, skills, hooks, or config.

SKILL.md

.github/skills/cc-changelogView on GitHub ↗
---
name: cc-changelog
description: |
  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.
argument-hint: "[--full|--set=VERSION]"
effort: medium
---

# 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 truth

More from oliver-kriska/claude-elixir-phoenix

SkillDescription
ash-frameworkAsh Framework — resources, actions, policies, aggregates, calculations, AshPhoenix.Form, LiveView, migrations. Use when generating resources via mix ash.codegen, editing changes, checks, types, validations, or domain code interfaces.
catchupSummarize 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.
codex-abRun an A/B codex review experiment — holistic codex review vs 3 focused dimension passes (security, ecto, liveview) on the branch diff, classify findings, report a panel-value verdict. Use when the branch is fresh, before any codex review runs.
compound-docsSearchable Elixir/Phoenix/Ecto solution documentation system with YAML frontmatter. Builds institutional knowledge from solved problems. Use when consulting past solutions before investigating new issues.
docs-check|
ecto-n1-checkDetect N+1 query anti-patterns specifically — Repo calls inside Enum/for
ecto-patternsEcto patterns — schemas, changesets, queries, migrations, Multi, associations, preloads, upserts. Use when editing Repo calls, Ecto.Query, or schema fields. Skip for Ash.
ecto:constraint-debugDebug Ecto constraint violations - trace triggers, check migrations, find duplicate data. Use when seeing unique_constraint, foreign_key_constraint, or check_constraint errors.
ecto:n1-checkDetect N+1 query anti-patterns specifically — Repo calls inside Enum/for loops, missing preloads on associations. Use when N+1 is explicitly suspected, NOT for unrelated Ecto questions or wider database performance.
elixir-idiomsOTP/BEAM patterns and Elixir idioms — GenServer, Supervisor, Task, Registry, pattern matching, with chains, pipes. Use when designing processes or debugging BEAM issues.