plugins/dev-tools/skills/evolving-config/SKILL.md
Audit Claude Code configuration against latest features and best practices. Use when user says "evolve", "self-improve", "audit config", "what's new in claude code", "upgrade configuration", "check for improvements", "are we up to date".
npx skillsauth add alexei-led/claude-code-config evolving-configInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Audit Claude Code config against latest capabilities. Conservative by default — says "no changes needed" when that's true.
<!-- CC-ONLY: begin -->Use TaskCreate to track these 6 phases:
<!-- CC-ONLY: end -->Read ALL config files in parallel:
# Glob these patterns
CLAUDE.md # Root instructions
.claude/CLAUDE.md # Project instructions
.claude/settings.json # Settings + hooks
.claude/settings.local.json # Local overrides
.claude/skills/*/SKILL.md # All skills
.claude/agents/*.md # All agents (if present)
.claude/commands/**/*.md # All commands (if present)
hooks/* # Hook scripts
Build inventory summary:
| Category | Count | Details | | ----------- | ----- | ----------------------------- | | Skills | N | list names | | Agents | N | list names | | Commands | N | list names | | Hooks | N | list events | | MCP servers | N | list names | | Model refs | list | which models referenced where |
Note any staleness indicators (outdated model names, deprecated patterns).
Fetch the Claude Code changelog:
WebFetch(
url="https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md",
prompt="Extract ALL features, changes, and deprecations from the last 6 months. Group by: new features, configuration changes, breaking changes, new hook events, new settings, new CLI flags, new MCP capabilities, new agent types. Be thorough."
)
If WebFetch fails or returns insufficient data, note the gap and rely on Phase 3.
Run two targeted web research queries:
If Perplexity returns cited URLs with high-value content, WebFetch top 2 for deeper details.
Compare current config against latest capabilities. For EACH category below, produce findings:
| Category | What to Check |
| ----------------- | ------------------------------------------------------------------------------ |
| Model routing | Are model assignments optimal? New models available? Effort levels configured? |
| Hooks | New hook events available? Async hooks? Hook v2 features? |
| Skills | Stale patterns? New tool types to leverage? Missing context: fork? |
| Agents | New subagent types? Agent features (memory, skills)? |
| MCP servers | New useful servers? Deprecated transports? OAuth improvements? |
| Permissions | New permission syntax? Over-permissive rules? Missing deny rules? |
| Settings | New settings fields? Deprecated options? Sandbox improvements? |
| CLAUDE.md | Outdated instructions? Stale references? Missing new patterns? |
| Teams | New team features? Configuration improvements? |
| Commands | Deprecated command patterns? New frontmatter fields? |
For each finding, assign ONE rating:
| Rating | Criteria | Action | | ------------------ | ----------------------------------------------- | ---------------- | | STILL GOOD | Current config matches or exceeds best practice | No change needed | | DEPRECATED | Feature removed or replaced upstream | Must update | | WORTH ADOPTING | Clear value, low disruption, proven stable | Recommend | | NICE-TO-HAVE | Minor improvement, some disruption | Mention only | | NOT YET | Too experimental or doesn't fit workflow | Skip or note |
Critical rule: Default classification is STILL GOOD. A finding must clear the bar: "Is this worth the disruption?" Changing working config has real cost — context relearning, potential breakage, testing overhead. Only promote to WORTH ADOPTING when the benefit clearly exceeds that cost.
Cap: Maximum 10 recommendations across WORTH ADOPTING + DEPRECATED. If more exist, prioritize by impact and note the overflow.
Format the report:
## Configuration Audit Report
**Date**: {date}
**Changelog checked through**: {version or date}
**Sources**: {list: changelog, perplexity, docs URLs}
### What's Working Well (STILL GOOD)
- {explicit acknowledgment of things that don't need changing}
- {this section should be the longest — most config should be fine}
### Action Required (DEPRECATED)
- {breaking changes or removed features — empty is normal}
### Recommended Updates (WORTH ADOPTING)
- {high-value, low-disruption improvements}
- {each item: what to change, why, and estimated disruption}
### On Your Radar (NICE-TO-HAVE)
- {minor improvements that can wait}
### Not Yet (TOO EARLY)
- {experimental features, not ready for production config}
### Summary
- {X} areas reviewed — no changes needed
- {Y} updates recommended
- {Z} items informational
STOP here.
<!-- CC-ONLY: begin -->Use AskUserQuestion. Ask one question at a time:
| Header | Question | Options | | ------ | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | Action | How should we proceed with the audit results? | Apply all recommended (Recommended) / Select items to apply / Dry run only (show diffs) / Skip (report only) |
<!-- CC-ONLY: end -->If $ARGUMENTS contains --dry-run: Skip the question, show diffs only, do not apply.
Based on user selection:
When describing how to avoid overreach, include this explicit gate: "I will not make major/risky config changes unless you confirm the named files and risks."
If user selected "Dry run only": show what each edit would look like, then stop.
--dry-run flag in arguments: Show full report, skip Phase 6tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.