Skip to content
cccskills
FreePublished on GitHub

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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md3.4 KB
  • references/analysis-rules.md5.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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:

CategoryMeaningAction
BREAKINGMay break existing plugin functionalityImmediate fix required
OPPORTUNITYNew CC feature the plugin could useAdd to backlog/plan
RELEVANT FIXCC fixed a bug we worked aroundCheck if workaround can be removed
DEPRECATIONCC removing something we usePlan migration
INFOGood to know, no action neededLog 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:

  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

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Analyze a legacy app in any language before rewriting it in Elixir: inventory, features as goals, why each mechanism exists, runtime topology, external contracts. Use to start or refresh a rewrite.

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

Design the idiomatic Elixir architecture for a rewrite: set the compatibility bar (ADR-000), consult phx specialists on open questions, then build contexts, ledger and ADRs. Use after /rewrite:analyze.

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

Ash 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.

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

Ash Framework — resources, actions, policies, aggregates; Use when generating resources via mix ash.codegen, editing…

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

Compatibility alias for the Elixir/Phoenix plugin's LiveView assigns audit. Invoke explicitly with /lv:assigns.

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

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.

The English summary is being prepared. Showing the original description.

oliver-kriska/claude-elixir-phoenix569Updated Oct 22, 2026

See all skills by oliver-kriska

Report a problem with this skill