Review Claude Code CLI changelog updates against the user's dotfiles configuration and recommend which new features are worth adopting. Make sure to use this skill whenever the user mentions "claude code ๋ณ๊ฒฝ์ฌํญ", "์ฒด์ธ์ง๋ก๊ทธ ๊ฒํ ", "claude code ์ ๋ฐ์ดํธ ๊ฒํ ", "release notes ๊ฒํ ", "๋ฒ์ X ์ถ๊ฐํ ๊ฑฐ", "์ต๊ทผ ๋ฆด๋ฆฌ์ค ๋ญ์๋", "claude code changelog review", references CHANGELOG.md or anchor URLs like
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Review Claude Code CLI changelog updates against the user's dotfiles configuration and recommend which new features are worth adopting. Make sure to use this skill whenever the user mentions "claude code ๋ณ๊ฒฝ์ฌํญ", "์ฒด์ธ์ง๋ก๊ทธ ๊ฒํ ", "claude code ์ ๋ฐ์ดํธ ๊ฒํ ", "release notes ๊ฒํ ", "๋ฒ์ X ์ถ๊ฐํ ๊ฑฐ", "์ต๊ทผ ๋ฆด๋ฆฌ์ค ๋ญ์๋", "claude code changelog review", references CHANGELOG.md or anchor URLs like
Claude Code CLI Changelog Review
Compares recent Claude Code CLI releases against the user's dotfiles configuration and produces tiered, actionable recommendations.
Output only โ never auto-apply changes. The user must explicitly choose what to adopt; that's the contract. Editing dotfiles silently would burn trust faster than any time saved.
Why this exists
Claude Code ships rapid releases, often multiple per week. Each release contains 10-30 bullets, mostly bug fixes that don't need action โ but a few introduce new hook fields, settings keys, or env vars that map directly to the user's existing dotfiles setup. Reading one release manually is feasible; doing the cross-reference across 5-10 releases without structure is where things slip through.
This skill is the cross-reference. It exists because the user already has a sophisticated dotfiles harness (custom hooks, MCP servers, plugins, ENABLE_* env toggles), and updates from upstream that touch those exact surfaces are high-leverage to adopt โ but easy to miss if you scroll past them in a 30-bullet release.
Inputs
The user's request might come as:
Format
Example
Resolution
Range
2.1.120..2.1.128, 2.1.120 to 2.1.128
Inclusive both ends
Last N
last 5, ์ต๊ทผ 5๊ฐ
N most recent
Anchor URL
#21128
Strip #, restore dots โ 2.1.128
Single version
2.1.128
Just that one
Nothing
โ
Default to last 5
If the request is genuinely ambiguous, ask once. The bundled fetch script handles all of these formats including anchor normalization.
Workflow
The natural order is fetch โ read user config โ categorize โ tier โ render. Adapt as needed โ if the conversation already contains the CHANGELOG, skip fetch; if .mcp.json doesn't exist, skip that read; if the user asks just about a single category (e.g., "hook ๊ด๋ จ๋ง ๋ด"), narrow accordingly.
Fetch
Use the bundled script. It handles gh rate-limit fallback, version filtering, and anchor normalization in one place โ three things that are individually easy to get wrong:
~/.dotfiles/.claude/skills/cc-changelog-review/scripts/fetch-changelog.sh # last 5
~/.dotfiles/.claude/skills/cc-changelog-review/scripts/fetch-changelog.sh 10 # last N
~/.dotfiles/.claude/skills/cc-changelog-review/scripts/fetch-changelog.sh 2.1.128
~/.dotfiles/.claude/skills/cc-changelog-review/scripts/fetch-changelog.sh 2.1.120 2.1.128
~/.dotfiles/.claude/skills/cc-changelog-review/scripts/fetch-changelog.sh '#21128'
Why a script and not inline gh api: deterministic fallback (gh โ curl), correct anchor handling, and avoidance of macOS-specific bash gotchas (BSD awk doesn't emit \0, awk exit triggers SIGPIPE under set -e). The script encodes those once.
~/.dotfiles/.mcp.json (if present) โ MCP server configuration
~/.dotfiles/zsh/path.zsh โ ENABLE_* env vars
~/.dotfiles/zsh/functions.zsh โ AI CLI wrappers (ccv, cco, gem, cdx) and their flags
~/.claude/projects/-Users-sskim--dotfiles/memory/MEMORY.md (if present โ and linked memory files when relevant) โ multi-machine context, security posture, prior decisions
ls ~/.dotfiles/.claude/hooks/ โ hook script names
ls ~/.dotfiles/.claude/skills/ โ skill names
Reading in parallel matters because the cross-reference is the whole point โ having all files in context simultaneously means you don't re-read the same file three times when classifying different bullets.
The memory file matters specifically because some recommendations only make sense with cross-machine context (e.g., recommending prUrlTemplate requires knowing the user has a company Mac with a different git remote; recommending shell-config deny rules requires knowing they sync dotfiles across machines). Without that context, recommendations look generic and the user dismisses them as noise.
Categorize each bullet
Apply the mapping in references/category-mapping.md โ read it now if you haven't this session. The table covers 14 categories (hooks, MCP, env vars, permissions, skills, slash commands, themes, plugins, CLI, vim, statusline, auto/plan mode, plus per-category notes that capture this user's specific posture).
One bullet can touch multiple categories. Don't force a 1:1 mapping; record both/all.
Assign Tier
Tier 1 โ ์ฆ์ ํจ๊ณผ: Maps to existing user config; user can enable now with a small edit. This is where leverage lives โ the whole reason to read the changelog.
Tier 2 โ ์ํฌํ๋ก์ฐ ์ถ๊ฐ: New optional capability requiring fresh config (alias, hook, env var, skill placeholder).
Skip: Pure bug fixes โ note in the summary line, don't list.
If a candidate would actually require touching 5+ files, demote it from Tier 1 to Tier 2. The "small edit" criterion is what makes Tier 1 useful as a signal โ once it stops being small, the user reads the tier label as a lie.
Render
The output should convey, at minimum:
Version range covered, total bullets, bullets-after-bug-filter
One concrete top recommendation with reasoning (why it's the highest leverage โ token cost, maintenance load, fit with existing posture)
Tables work well for the tier sections because they compress the cross-reference. Korean output (matches the user's language: korean setting), but technical identifiers stay in original form.
End with: "์ด๋ ํญ๋ชฉ์ ์ ์ฉํ ๊น์? ๋๋ '์ ์ฒด ๊ฒํ ๋ง'์ผ๋ก ๋ตํ์๋ฉด ์ข ๋ฃํฉ๋๋ค." The closing question is the contract โ review-only means waiting for explicit selection before any write.
This is a guideline, not a contract โ adapt the headings and column count to fit what's actually in the range. If a Tier is empty, omit it entirely rather than printing "(์์)".
Verify before recommending
Before recommending a setting, run jq '.path.to.key' ~/.dotfiles/.claude/settings.json. If it's already set, drop the recommendation โ it's noise, and the user trusts you to filter that out. The cost of one wasted recommendation is high because each one trains them to skim the next.
Cite paths
Every recommendation referencing existing config must include file_path:line_number. The user navigates with this โ they shouldn't have to grep to verify your claim.
Gotchas
These are mistakes that look reasonable but burn time. Worth re-reading on each invocation.
GitHub gh rate limit is shared across all gh-using tools/agents in the session (5,000/hr). One CHANGELOG fetch is cheap, but if the session already used many gh calls earlier, fall back to curl/WebFetch immediately rather than retrying. The bundled script does this automatically.
Anchor format strips dots: #21128 = section ## 2.1.128, not ## 2.11.28. Restore dots as X.Y.{rest}. The fetch script handles this; if you parse manually, watch for it.
Canonical settings path is ~/.dotfiles/.claude/settings.json, not ~/.claude/settings.json (the latter is a symlink). Recommend edits at the dotfiles location so changes are tracked in git.
One bullet can touch multiple categories โ don't force 1:1. "Added env var X with permission Y" hits both env and permissions.
ENABLE_TOOL_SEARCH=1 in settings means MCP-related changelog items are higher leverage โ items announcing "always-loaded tools" matter more for users with deferred loading.
Pre-commit hooks may modify files on commit (e.g., end-of-file-fixer). After recommending an edit, expect a possible re-staging cycle on the user's next commit โ that's the same change, not a different one.
Some bullets are deprecation announcements, not new features. e.g., "/cost merged into /usage" means update spinnerTipsOverride.tips references, not enable a new capability.
Scope creep: a Tier 1 recommendation that spans 5+ files is actually a Tier 2 project. Re-tier when effort exceeds "small edit" โ users read tiers as effort signals, so mis-tiering breaks the signal.
Don't promote --dangerously-skip-permissions items to Tier 1 unless skipDangerousModePermissionPrompt: true is already set. Otherwise the user accepted the safer mode and the change requires opting back into a riskier path; that's an explicit decision, not a small edit.
Protection-shrinking changes are risk increases, not convenience wins. When a release announces "X path is no longer protected from skip-permissions" or "Y operation no longer prompts", the surface-level reading is "fewer interruptions" โ but for a user who already has skip-mode active (the only kind of user it affects), the actual effect is "previously-guarded files can now be silently rewritten by any agent". Surface this as a Tier 1 security review item with a deny-rule recommendation, not as "auto-applied, no action needed". A worked example: 2.1.126's --dangerously-skip-permissions expansion to .claude/, .git/, .vscode/, and shell config means a user with skipDangerousModePermissionPrompt: true plus a ccv -y alias has lost guardrails on their own dotfiles and shell init โ recommend explicit permissions.deny entries for those paths, not silence.
The skill cannot replace thinking. When the workflow says "categorize โ tier", that mechanizes the bookkeeping, not the judgment. Each Tier 1 candidate still needs the question "is this actually good for this user given this posture?" โ sometimes the answer flips the direction of the recommendation entirely (see the protection-shrinking gotcha above).
Listing items verbatim is the failure mode โ if your output mirrors the CHANGELOG, you've added no value. Filter aggressively.
Files
references/category-mapping.md โ full table of changelog-item categories and where each maps in the user's dotfiles, plus per-category notes that capture this user's specific posture (custom hooks, ENABLE_* pattern, etc.). Read it when categorizing bullets.
scripts/fetch-changelog.sh โ fetch + filter helper. Always prefer this over inline gh api calls; it handles fallback, anchor normalization, and macOS bash quirks.
