update-config

name	update-config
description	Review and improve the global Claude Code setup. Reads the config-review-queue and the config strategy, proposes and applies improvements to global agents/skills/hooks/rules/CLAUDE.md, then clears resolved queue entries. Invoke manually with /update-config.
disable-model-invocation	true

/update-config

Maintain and evolve the user's global Claude Code configuration. This is the manual entry point to the self-improvement loop. Delegate the heavy work to the config-manager subagent so this runs in a focused context.

Steps

1. Load context.

   • Read ~/.claude/skills/update-config/docs/strategy.md (the source of truth for direction).
   • Read ~/.claude/config-review-queue.md (the append-only friction log).
   • Note the current live config: ~/.claude/CLAUDE.md, ~/.claude/settings.json, and the contents of ~/.claude/{agents,skills,hooks,rules}/.

2. Delegate to config-manager. Spawn the config-manager subagent with the queue contents and strategy. Ask it to:

   • Triage each queue entry (apply / defer / discard) per the strategy's promotion rules.
   • Draft concrete edits (new skill, new agent, agent tweak, hook, rule, CLAUDE.md change).

3. Review with the user. Present the proposed changes grouped by type. Use AskUserQuestion for any judgment call. Apply only what's approved.

4. Apply. Make targeted edits with the file tools. Constraints:

   • Keep ~/.claude/CLAUDE.md under ~150 lines. Push procedures → skills, deterministic rules → hooks, isolated work → subagents.
   • Never modify the company env block in settings.json (LiteLLM base URL, auth token, model aliases). Preserve those values exactly.
   • Never invent credentials; suggest MCP additions and let the user run claude mcp add.

5. Clear resolved entries. Remove applied entries from ~/.claude/config-review-queue.md. Leave deferred ones with a one-line note. Keep the header intact.

6. Validate. Run claude doctor. Fix any reported config errors. Report a short summary of what changed and why.

Notes

• Backup markers left by the SessionEnd/PreCompact hook are just "this session may have friction" flags. If a marked session had no real friction, discard the marker.
• Durable rationale about why the config is shaped this way belongs in the config-manager's memory: user, not in the queue.