| name | update-claude |
| description | Summarize the current session and propose improvements to CLAUDE.md, rules, docs, and skills, applying them after user confirmation. Use only when explicitly invoked. |
| disable-model-invocation | true |
Summarize the current conversation and propose improvements to CLAUDE.md, rules, and skills.
Syntax: /update-claude
Placement rules
- One home per rule: grep
.claude/ for an existing statement before adding anywhere; extend the existing home, and put at most a one-line pointer elsewhere.
- Always-loaded files (
CLAUDE.md, AGENTS.md, .claude/rules/*.md without paths: frontmatter) hold only high-frequency, broadly-applicable rules in <=2 lines; worked examples and niche topics go to .claude/docs/.
- Every new
.claude/docs file must be added to .claude/docs/documentation-references.md.
- New skills need frontmatter (
name + a trigger-quality description); never add tables duplicating harness-injected lists.
- Topic guidance that should auto-load for certain files →
.claude/rules/*.md with paths: glob frontmatter.
Execution
1. Summarize the session
Review the full conversation and extract:
- What was built or changed — new files, refactored systems, validator additions, etc.
- Patterns discovered — recurring issues, anti-patterns, common mistakes found during the work.
- Rules applied or created — coding conventions, scripting patterns, or process rules that emerged.
- Decisions made — architectural choices, tradeoffs, why something was done a certain way.
2. Identify generalizable improvements
For each pattern or rule, assess whether it applies broadly or only to the specific task:
- Broad rules →
.claude/rules/general-rules.md or .claude/docs/localisation-rules.md
- Documentation references →
.claude/docs/
- Skill improvements →
.claude/skills/*/SKILL.md
- Project context (non-obvious, persists across sessions) → memory
Filter ruthlessly — only propose additions that:
- Cannot be derived by reading the current codebase
- Would prevent a future mistake or speed up future work
- Are general enough to apply beyond the specific files touched
3. Check existing documentation for staleness
Read the current state of:
CLAUDE.md — is the skill table up to date?.claude/rules/general-rules.md — any rules that conflict with what we learned?.claude/docs/localisation-rules.md — any gaps?AGENTS.md — any conventions needing updates?
Flag anything outdated or contradicting current practice.
4. Propose changes
Present a structured list:
## Rules to add/update
- [file] — [what to add] — [why]
## Skills to add/update
- [skill name] — [what changed] — [why]
## Documentation to update
- [file] — [what's stale] — [what it should say]
## Memory to save
- [type] — [content] — [why it matters for future sessions]
5. Apply changes (with confirmation)
After presenting the proposals, ask the user which to apply. Then:
- Edit the relevant files directly
- Update
CLAUDE.md skill table if new skills were added
- Save any memory items
Important Notes
- Do NOT add implementation details, file paths, or architecture derivable from reading the code.
- Do NOT duplicate what's already in AGENTS.md or existing rules files.
- Focus on why not what — rules should explain the reasoning so edge cases can be judged.
- Keep rules concise — one pattern per entry, with a wrong/right example where helpful.
- Check for conflicts before adding — grep the rules files to avoid contradictions.
