From claude-code
Reviews Claude Code release notes, filtering for relevance to your installed plugins, skills, tools, and platform. Use for 'what's new?', update checks, or changelog queries.
npx claudepluginhub bendrucker/claude --plugin claude-codeThis skill is limited to using the following tools:
**Current version**: `!`claude --version``
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Current version: !claude --version **Platform**: `!`uname -s
Installed plugins:
!`claude plugin list --json | jq -r '[.[] | select(.enabled) | .id] | unique | .[]'`
Use the GraphQL query at ${CLAUDE_SKILL_DIR}/references/releases.graphql to fetch releases in a single API call:
gh api graphql -F query=@${CLAUDE_SKILL_DIR}/references/releases.graphql -F owner=anthropics -F name=claude-code -F limit=10
Variables:
$owner (String!): Repository owner$name (String!): Repository name$limit (Int!): Number of releases to fetch. Default 10. Increase if the user asks for a broader range (e.g., "what changed in the last month?").Response shape: data.repository.releases.nodes[] with tagName, publishedAt (ISO 8601), and description (release notes markdown).
Also scan the project's .claude/ directory for settings, hooks, skills, and rules to understand what's in use.
Darwin, exclude Windows-only and PowerShell-related entries. If Linux, exclude macOS-specific entries.Categorize each relevant entry and order by impact within each category.
Features are major new capabilities that enable workflows that weren't possible before or significantly change how something works. Order by usefulness to this user, not by version. Interactive UX improvements (keyboard shortcuts, search, rendering tweaks) belong in Quality of Life, not Features. Prioritize features for human-interactive use over scripting/machine-use features (e.g., --bare, non-blocking MCP) unless the user specifically asks about automation.
Suggested Uses must reference the user's actual workflow plugins (e.g., things, linear, review:peer, pull-request) with concrete, thoughtful explanations of how the plugin would benefit. Never suggest uses for meta skills (claude-code:skill, claude-code:hook). If a feature has no concrete application to an installed plugin, omit Suggested Uses entirely.
Only mark a feature 🆕 if it's from a release published less than 7 days before today.
## Features
### Feature Title in Title Case 🆕
**Version:** 1.2.3 (3 days ago)
What the feature does and a concrete explanation of why this user should care.
#### Suggested Uses
* **things:** Store tag mappings in the plugin data directory so they persist across plugin updates, eliminating the need to re-configure after each update.
Bug Fixes, Performance, Quality of Life: Summarize each category in 2-3 sentences highlighting the most impactful changes. Don't list every entry. The goal is to extract what's useful, not mirror the changelog. If the user asks about a specific area, then go deeper on that area.