Feature Request: Proactive change management for breaking updates

First — Appreciation

The energy and velocity at Anthropic is remarkable. Claude Code has become the backbone of my personal knowledge management system, my automation infrastructure, and increasingly my cognitive assistant. The tool is transformative, and I'm deeply invested in its success.

That said, I have a concern that's becoming a recurring source of friction — and as someone who applies Lean Six Sigma methodology to my workflows, I can tell you it's creating measurable waste.

The Problem: Silent Changes Create Out-of-Control Processes

When Claude Code ships updates that deprecate features, change behavior, or restructure configuration, three things happen:

1. I don't know what changed. There's no proactive notification at session start that says "these things are different since your last session." I discover changes through breakage — a slash command that no longer works, a config field that moved, behavior that shifted.

1. My agents don't know what changed. This is worse. Claude itself doesn't know that /output-style was deprecated until I ask about it. The agent I'm relying on to manage my system doesn't have current knowledge of its own capabilities. It can't warn me about deprecations, suggest migration paths, or adapt its recommendations to the new reality.

1. My automation breaks silently. I've built hooks, skills, scripts, and workflows on top of Claude Code's API contract. When that contract changes without notice, my systems drift out of spec. In LSS terms, this is an out-of-control process — I can't maintain statistical control when the underlying platform shifts without measurement.

A Concrete Example: Output Styles

I built 21 custom output styles to manage Claude's communication patterns for different contexts — research, debugging, creative work, military-style briefings, Socratic teaching. This wasn't cosmetic; it was a control mechanism for agent behavior.

The progression:

• Phase 1: I discovered that output styles were being used to embed behavioral personas — identity overrides that could conflict with project instructions. I invested time auditing, classifying, and remediating this.
• Phase 2: /output-style was deprecated and replaced with a /config menu option. No migration guide, no timeline warning, no indication of where this was heading.
• Phase 3 (today): I discover the change mid-session, don't know what else changed, and now I have to audit whether my 21 styles still load correctly under the new system.

Each phase created rework. Each phase was discoverable only through breakage. The total cost isn't just the fix — it's the trust erosion. When I don't know what changed, I can't trust my system.

What I'm Asking For

When changes occur, Claude agents should intelligently and proactively help their users stabilize:

At Session Start (Automatic)

When a user starts a session after a Claude Code update, the agent should:

• Surface a brief summary of changes relevant to the user's configuration
• Flag any deprecations that affect the user's installed skills, hooks, output styles, or settings
• Recommend a stabilization plan, prioritized by impact

For example, after today's changes, a proactive agent would have told me at boot:

Update Notice: Claude Code updated since your last session. Changes affecting your setup: 1. /output-style deprecated — your 21 styles still work but are now set via /config or the outputStyle settings field. 2. max effort level removed — change references to high. 3. New CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 env var available — recommended for credential security. 4. isolation: "worktree" now available for agents — could resolve parallel agent git index.lock conflicts. 5. Agent Teams research preview available.

That's five sentences. It would have saved me an hour of confusion and frustration.

In Agent Memory (Persistent)

Claude's own knowledge should be updated when its capabilities change. An agent that doesn't know its own current feature set gives stale advice. This is the equivalent of deploying a new employee and not telling them what tools they have access to.

In Documentation (Accessible)

A machine-readable changelog that agents can query — not just a human-readable blog post, but a structured diff that Claude can parse at session start and cross-reference against the user's configuration.

The LSS Framing

In Lean Six Sigma, an out-of-control process is one where variation exceeds the control limits. The control limits for my Claude Code system are:

• Known inputs: I know what version I'm running, what features are available, what configuration is active
• Predictable behavior: Given the same inputs, Claude behaves consistently
• Measurable outputs: I can verify that my automation produces expected results

Silent updates violate all three. This is textbook special cause variation — and the fix isn't to tighten my process (I'm already running 15 hooks across 8 events). The fix is to control the input variation at the source.

Summary — Five Asks

1. Proactive notification at session start when breaking changes affect the user's config
2. Agent self-awareness of its own current capabilities and recent changes
3. Machine-readable changelogs that agents can query and cross-reference
4. Deprecation timelines — not just "this is deprecated" but "this will be removed in X, here's the migration path"
5. Stabilization guidance — when you change something, tell the agent how to help the user adapt

The users who are building the most sophisticated systems on Claude Code are the ones most affected by unmanaged change. We're also your most valuable signal for what works and what doesn't. Help us help you by keeping us informed.