upstream: official claude code updates 2026-05-21

docs/comparisons/README.md

@@ -50,3 +50,5 @@ side-by-side pricing for all tools in one table: [pricing.md](pricing.md)
 note: upstream tool versions and pricing verified as of april 2026
 
 **note: tool versions and pricing verified as of may 13 2026 (claude code v2.1.140). these tools and their pricing change frequently. verify current status before recommending to users.**
+
+**note: tool versions and pricing verified as of may 2026 (claude code v2.1.146). these tools and their pricing change frequently. verify current status before recommending to users.**

docs/hooks.md

@@ -38,21 +38,6 @@ a hook:
 | stale-branch | SessionStart | warns about local branches with deleted remotes |
 | notify | Notification | routes claude code alerts to macOS notifications |
 
-hook fire frequency is driven by tool usage. from real session data:
-
-| tool event | fires | what triggers hooks |
-|------------|-------|-------------------|
-| Bash (10,153) | most hook-triggering | safety-guard, no-squash, commit-nudge all fire on Bash |
-| Read (9,187) | panopticon logs these | panopticon tracks all read operations |
-| Edit (5,010) | panopticon tracks | md-lint-fix fires on .md edits, commit-nudge counts edits |
-| Write (1,696) | panopticon tracks | version-stamp checks written files at SessionEnd |
-
-PreToolUse hooks (safety-guard, no-squash) fire on every Bash call -- 10K+ times across all sessions. that's why they need to be fast (< 50ms).
-
----
-
-
-
 ### hook performance notes (v2.1.140+)
 PreToolUse hooks on Bash commands need to complete in <50ms to avoid user-facing latency. the hooks listed above are optimized for speed -- they use jq for JSON parsing and regex for pattern matching rather than spawning subprocesses. profile your custom hooks with `time` if you add new ones.
 

docs/session-workflow.md

@@ -28,6 +28,11 @@ the order matters: CLAUDE.md sets the rules, skills give capabilities, hooks enf
 
 ## the cascade method
 
+
+
+
+**v2.1.146 note**: `/simplify` was renamed to `/code-review` with optional effort parameter (e.g., `/code-review high`). use this to request code reviews at different detail levels without changing your session mode.
+
 ## when to /compact vs /clear
 
 from real data: 32% of 30-60 min sessions needed compaction, 54% of 2hr+ sessions did. here's when to use each:

docs/tips/README.md

@@ -21,3 +21,5 @@ short, standalone claude code tips. each one is a specific technique you can use
 | [monitor](./monitor.md)
 
 | [monitor](./monitor.md) | watch background processes, react to output in real time (v2.1.98+, stable as of v2.1.145) |
+
+| [code review](./code-review.md) | use /code-review with effort levels for structured review passes |

docs/tips/context-management.md

@@ -94,6 +94,11 @@ the [context-save.sh](../../hooks/context-save.sh) hook in this repo does exactl
 
 across hundreds of sessions, roughly a fifth of them hit compaction. the pattern is predictable: short sessions almost never compact. once you're past 30 minutes, about a third of sessions will compact. past an hour, it's a coin flip. my rule is simple: if a session compacts twice, finish the immediate task and start fresh. three compactions means the original plan is gone and you're flying blind. sessions that compact once still ship at the same rate as sessions that don't. sessions that compact twice ship at half the rate. keep sessions focused and under an hour. if a task needs two hours, split it into three focused sessions.
 
+
+
+
+**v2.1.146 update**: diff rendering performance improved for large file edits. this may slightly reduce tool execution time on sessions with many multi-file changes, but compaction patterns remain consistent.
+
 ## try it
 
 1. run `/mine` to check your compaction rate by session length. if most 30-min sessions are compacting, your prompts are too broad.

docs/tips/fast-mode.md

@@ -8,6 +8,11 @@ fast mode keeps you on opus. it does not switch to a cheaper or smaller model. w
 
 this is the most common misconception i see. people assume fast mode = dumber model. it's not. it's the same opus with a tighter thinking budget.
 
+
+
+
+> **v2.1.146 note**: `/simplify` was renamed to `/code-review` with optional effort level (e.g. `/code-review high`). this lets you request lighter or heavier review passes without switching modes.
+
 ## why i don't use it
 
 never use fast mode. i mean it. the only scenario where fast mode makes sense is if you're at a hackathon with 30 minutes left before demo, or you're someone who literally doesn't care about burning through usage. fast mode can easily run up over a hundred dollars of usage in half an hour.