docs: Sync all documentation with Claude Code February 2026 features
Update 23 files across all 10 tutorial directories and 7 reference documents to match the latest Claude Code v2.1+ features and correct outdated content including model names (4.5→4.6), permission modes, hook events, CLI syntax, MCP config paths, plugin manifest format, checkpoint commands, session management, and URLs. Add documentation for new features: Auto Memory, Remote Control, Web Sessions, Desktop App, Agent Teams, MCP OAuth, Task List, Sandboxing, and more.
This commit is contained in:
@@ -2,6 +2,8 @@
|
||||
|
||||
Real-world examples of using checkpoints effectively in Claude Code.
|
||||
|
||||
Note: Checkpoints are created automatically with every user prompt. You do not need to manually save them. To rewind, press `Esc` twice (`Esc+Esc`) or use `/rewind` to open the checkpoint browser.
|
||||
|
||||
## Example 1: Database Migration
|
||||
|
||||
### Scenario
|
||||
@@ -10,53 +12,32 @@ You need to migrate from MySQL to PostgreSQL but want to explore both a direct m
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Before database migration"
|
||||
|
||||
User: Let's implement a direct migration from MySQL to PostgreSQL
|
||||
[Checkpoint A created automatically]
|
||||
|
||||
Claude: I'll implement the direct migration...
|
||||
[Changes database driver, updates queries, modifies schema]
|
||||
|
||||
User: /checkpoint save "Direct migration complete"
|
||||
|
||||
User: Run the tests
|
||||
[Checkpoint B created automatically]
|
||||
|
||||
Claude: Running tests...
|
||||
❌ 15 tests failing - connection pool issues
|
||||
|
||||
User: This approach has issues. Let's try the dual-write pattern instead.
|
||||
|
||||
Claude: I'll rewind to the starting point...
|
||||
/checkpoint rewind "Before database migration"
|
||||
[User presses Esc+Esc, selects Checkpoint A, chooses "Restore code and conversation"]
|
||||
|
||||
User: Now implement a dual-write pattern where we write to both databases
|
||||
|
||||
Claude: I'll implement dual-write migration...
|
||||
[Implements dual-write layer, gradual migration strategy]
|
||||
|
||||
User: /checkpoint save "Dual-write migration complete"
|
||||
|
||||
User: Run the tests
|
||||
|
||||
Claude: Running tests...
|
||||
✅ All tests passing
|
||||
|
||||
User: /checkpoint compare "Direct migration complete" "Dual-write migration complete"
|
||||
|
||||
Claude: Comparison of the two approaches:
|
||||
|
||||
Direct Migration:
|
||||
- Faster to implement
|
||||
- All-or-nothing cutover
|
||||
- Higher risk
|
||||
- Failed integration tests
|
||||
|
||||
Dual-Write Migration:
|
||||
- More complex implementation
|
||||
- Gradual, safer migration
|
||||
- Can rollback easily
|
||||
- All tests passing
|
||||
- Recommended approach ✅
|
||||
User: The dual-write approach is clearly safer. Let's commit this.
|
||||
```
|
||||
|
||||
## Example 2: Performance Optimization
|
||||
@@ -67,47 +48,47 @@ Multiple performance optimization strategies to try.
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Baseline performance"
|
||||
|
||||
User: Let's optimize the API response time. Current: 450ms
|
||||
[Checkpoint "Baseline" created automatically]
|
||||
|
||||
Claude: I'll add database query caching...
|
||||
[Implements Redis caching]
|
||||
|
||||
User: /checkpoint save "Redis caching"
|
||||
User: Run performance tests
|
||||
|
||||
Claude: Results: 280ms average response time (38% improvement)
|
||||
|
||||
User: /checkpoint rewind "Baseline performance"
|
||||
User: Let me try a different approach.
|
||||
[User presses Esc+Esc, selects "Baseline" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Try database query optimization instead
|
||||
|
||||
Claude: I'll optimize database queries...
|
||||
[Adds indexes, optimizes N+1 queries]
|
||||
|
||||
User: /checkpoint save "Query optimization"
|
||||
User: Run performance tests
|
||||
|
||||
Claude: Results: 180ms average response time (60% improvement)
|
||||
|
||||
User: /checkpoint rewind "Baseline performance"
|
||||
User: Let me also try a third approach.
|
||||
[User presses Esc+Esc, selects "Baseline" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Try response compression and CDN
|
||||
|
||||
Claude: I'll add compression and CDN...
|
||||
[Implements gzip, sets up CDN]
|
||||
|
||||
User: /checkpoint save "Compression + CDN"
|
||||
User: Run performance tests
|
||||
|
||||
Claude: Results: 320ms average response time (29% improvement)
|
||||
|
||||
User: Let's combine query optimization with caching
|
||||
User: Query optimization was the best. Let me go back and combine it with caching.
|
||||
[User presses Esc+Esc, selects the checkpoint after query optimization, chooses "Restore code and conversation"]
|
||||
|
||||
Claude: I'll rewind to query optimization and add caching...
|
||||
/checkpoint rewind "Query optimization"
|
||||
[Adds Redis caching on top of optimized queries]
|
||||
User: Now add Redis caching on top of these optimized queries
|
||||
|
||||
Claude: [Adds Redis caching on top of optimized queries]
|
||||
|
||||
User: /checkpoint save "Combined approach"
|
||||
User: Run performance tests
|
||||
|
||||
Claude: Results: 95ms average response time (79% improvement) 🎉
|
||||
@@ -123,39 +104,43 @@ Trying different layouts for a dashboard.
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Dashboard - current layout"
|
||||
|
||||
User: Let's redesign the dashboard with a sidebar layout
|
||||
[Checkpoint "Start" created automatically]
|
||||
|
||||
Claude: [Implements sidebar layout]
|
||||
User: /checkpoint save "Sidebar layout"
|
||||
|
||||
User: Show me a screenshot
|
||||
|
||||
Claude: [Shows screenshot]
|
||||
|
||||
User: The sidebar feels cramped. Let's try a top navigation instead.
|
||||
[User presses Esc+Esc, selects "Start" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Try a top navigation layout
|
||||
|
||||
Claude: [Implements top navigation]
|
||||
|
||||
Claude: /checkpoint rewind "Dashboard - current layout"
|
||||
[Implements top navigation]
|
||||
User: /checkpoint save "Top navigation layout"
|
||||
User: Show me a screenshot
|
||||
|
||||
Claude: [Shows screenshot]
|
||||
|
||||
User: Better, but let's try a card-based grid layout
|
||||
[User presses Esc+Esc, selects "Start" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Try a card-based grid layout
|
||||
|
||||
Claude: [Implements card grid]
|
||||
|
||||
Claude: /checkpoint rewind "Dashboard - current layout"
|
||||
[Implements card grid]
|
||||
User: /checkpoint save "Card grid layout"
|
||||
User: Show me a screenshot
|
||||
|
||||
Claude: [Shows screenshot]
|
||||
|
||||
User: This is great! But can we combine the top nav with the card grid?
|
||||
[User presses Esc+Esc, selects the checkpoint after the card grid, chooses "Restore code and conversation"]
|
||||
|
||||
Claude: /checkpoint rewind "Card grid layout"
|
||||
[Adds top navigation to card grid]
|
||||
User: /checkpoint save "Top nav + card grid"
|
||||
User: Add top navigation to the card grid layout
|
||||
|
||||
Claude: [Adds top navigation to card grid]
|
||||
|
||||
User: Perfect! This is the final design.
|
||||
```
|
||||
@@ -169,34 +154,37 @@ Hunting down a tricky bug with multiple hypotheses.
|
||||
|
||||
```
|
||||
User: There's a memory leak in the application
|
||||
[Checkpoint "Before debugging" created automatically]
|
||||
|
||||
Claude: Let me investigate...
|
||||
[Analyzes code]
|
||||
|
||||
User: /checkpoint save "Before debugging"
|
||||
|
||||
User: I think it's in the event listeners. Let's fix those.
|
||||
|
||||
Claude: [Fixes event listener cleanup]
|
||||
User: /checkpoint save "Event listener fix"
|
||||
|
||||
User: Run memory profiler
|
||||
|
||||
Claude: Still leaking memory - event listeners weren't the issue
|
||||
|
||||
User: /checkpoint rewind "Before debugging"
|
||||
User: Let me go back and try a different hypothesis.
|
||||
[User presses Esc+Esc, selects "Before debugging" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Maybe it's the database connections?
|
||||
|
||||
Claude: [Implements connection pooling fixes]
|
||||
User: /checkpoint save "Connection pooling fix"
|
||||
|
||||
User: Run memory profiler
|
||||
|
||||
Claude: Still leaking - not the connections either
|
||||
|
||||
User: /checkpoint rewind "Before debugging"
|
||||
User: Let me go back and try another angle.
|
||||
[User presses Esc+Esc, selects "Before debugging" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Let's check for circular references
|
||||
|
||||
Claude: [Finds and fixes circular references in cache]
|
||||
User: /checkpoint save "Circular reference fix"
|
||||
|
||||
User: Run memory profiler
|
||||
|
||||
Claude: ✅ Memory leak fixed! The circular references in the caching layer were the culprit.
|
||||
@@ -212,51 +200,30 @@ Designing a REST API with multiple iterations.
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Before API design"
|
||||
|
||||
User: Create a REST API for our blog platform
|
||||
[Checkpoint "Before API design" created automatically]
|
||||
|
||||
Claude: [Creates basic CRUD API]
|
||||
User: /checkpoint save "Basic CRUD API"
|
||||
|
||||
User: This is too simple. Let's add pagination and filtering
|
||||
|
||||
Claude: [Adds pagination and filtering]
|
||||
User: /checkpoint save "API with pagination"
|
||||
|
||||
User: We need better resource relationships
|
||||
|
||||
Claude: [Implements HATEOAS links]
|
||||
User: /checkpoint save "API with HATEOAS"
|
||||
|
||||
User: Actually, let's try GraphQL instead of REST
|
||||
[User presses Esc+Esc, selects "Before API design" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
Claude: /checkpoint rewind "Before API design"
|
||||
[Implements GraphQL API]
|
||||
User: /checkpoint save "GraphQL API"
|
||||
User: Implement a GraphQL API for our blog platform instead
|
||||
|
||||
User: /checkpoint compare "API with HATEOAS" "GraphQL API"
|
||||
Claude: [Implements GraphQL API]
|
||||
|
||||
Claude: Comparison:
|
||||
User: I think REST is better for our use case.
|
||||
[User presses Esc+Esc, selects the checkpoint after HATEOAS, chooses "Restore code and conversation"]
|
||||
|
||||
REST with HATEOAS:
|
||||
+ Simple, well-understood
|
||||
+ Easy to cache
|
||||
+ Works with existing tools
|
||||
- Multiple round trips
|
||||
- Over-fetching data
|
||||
|
||||
GraphQL:
|
||||
+ Single endpoint
|
||||
+ Client specifies data needs
|
||||
+ No over-fetching
|
||||
- More complex setup
|
||||
- Harder to cache
|
||||
- Steeper learning curve
|
||||
|
||||
User: For our use case, REST is better. Let's go with that.
|
||||
|
||||
Claude: /checkpoint rewind "API with HATEOAS"
|
||||
User: Let's finalize the REST approach.
|
||||
```
|
||||
|
||||
## Example 6: Configuration Management
|
||||
@@ -267,21 +234,22 @@ Testing different configuration approaches.
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Original config"
|
||||
|
||||
User: Move configuration to environment variables
|
||||
[Checkpoint "Original config" created automatically]
|
||||
|
||||
Claude: [Implements env var configuration]
|
||||
User: /checkpoint save "Env var config"
|
||||
|
||||
User: Test in development
|
||||
|
||||
Claude: Works locally but deployment issues in production
|
||||
|
||||
User: /checkpoint rewind "Original config"
|
||||
User: Let me try a different approach.
|
||||
[User presses Esc+Esc, selects "Original config" checkpoint, chooses "Restore code and conversation"]
|
||||
|
||||
User: Try a config file approach with validation
|
||||
|
||||
Claude: [Implements YAML config with JSON schema validation]
|
||||
User: /checkpoint save "Config file with validation"
|
||||
|
||||
User: Test in development
|
||||
|
||||
Claude: ✅ Works well, good validation errors
|
||||
@@ -289,7 +257,7 @@ Claude: ✅ Works well, good validation errors
|
||||
User: Can we also support env vars for sensitive values?
|
||||
|
||||
Claude: [Adds env var override for secrets]
|
||||
User: /checkpoint save "Hybrid config approach"
|
||||
|
||||
User: Test deployment
|
||||
|
||||
Claude: ✅ All environments working correctly
|
||||
@@ -305,12 +273,11 @@ Implementing comprehensive testing.
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: /checkpoint save "Before adding tests"
|
||||
|
||||
User: Add unit tests for the auth module
|
||||
[Checkpoint created automatically]
|
||||
|
||||
Claude: [Adds Jest unit tests]
|
||||
User: /checkpoint save "Unit tests only"
|
||||
|
||||
User: Run tests
|
||||
|
||||
Claude: 45 tests passing, 78% coverage
|
||||
@@ -318,7 +285,7 @@ Claude: 45 tests passing, 78% coverage
|
||||
User: Add integration tests too
|
||||
|
||||
Claude: [Adds integration tests]
|
||||
User: /checkpoint save "Unit + Integration tests"
|
||||
|
||||
User: Run tests
|
||||
|
||||
Claude: 89 tests passing, 92% coverage, but tests are slow (3 minutes)
|
||||
@@ -326,7 +293,7 @@ Claude: 89 tests passing, 92% coverage, but tests are slow (3 minutes)
|
||||
User: The tests are too slow. Let's optimize.
|
||||
|
||||
Claude: [Optimizes test setup, adds parallel execution]
|
||||
User: /checkpoint save "Optimized tests"
|
||||
|
||||
User: Run tests
|
||||
|
||||
Claude: 89 tests passing, 92% coverage, 35 seconds ✅
|
||||
@@ -334,7 +301,7 @@ Claude: 89 tests passing, 92% coverage, 35 seconds ✅
|
||||
User: Great! Now add E2E tests for critical paths
|
||||
|
||||
Claude: [Adds Playwright E2E tests]
|
||||
User: /checkpoint save "Full test suite"
|
||||
|
||||
User: Run all tests
|
||||
|
||||
Claude: 112 tests passing, 94% coverage, 2 minutes
|
||||
@@ -342,11 +309,31 @@ Claude: 112 tests passing, 94% coverage, 2 minutes
|
||||
User: Perfect balance of coverage and speed!
|
||||
```
|
||||
|
||||
## Example 8: Using Summarize from Checkpoint
|
||||
|
||||
### Scenario
|
||||
After a long debugging session, you want to condense the conversation while preserving context.
|
||||
|
||||
### Workflow
|
||||
|
||||
```
|
||||
User: [After 20+ messages of debugging and exploration]
|
||||
|
||||
[User presses Esc+Esc, selects an early checkpoint, chooses "Summarize from here"]
|
||||
[Optionally provides instructions: "Focus on what we tried and what worked"]
|
||||
|
||||
Claude: [Generates a summary of the conversation from that point forward]
|
||||
[Original messages are preserved in the transcript]
|
||||
[The summary replaces the visible conversation, reducing context window usage]
|
||||
|
||||
User: Now let's continue with the approach that worked.
|
||||
```
|
||||
|
||||
## Key Takeaways
|
||||
|
||||
1. **Checkpoint before major changes**: Always create a checkpoint before significant modifications
|
||||
2. **Name checkpoints descriptively**: Use clear names that explain what was accomplished
|
||||
3. **Compare approaches**: Use checkpoint diff to evaluate different solutions
|
||||
1. **Checkpoints are automatic**: Every user prompt creates a checkpoint -- no manual saving needed
|
||||
2. **Use Esc+Esc or /rewind**: These are the two ways to access the checkpoint browser
|
||||
3. **Choose the right restore option**: Restore code, conversation, both, or summarize depending on your needs
|
||||
4. **Don't fear experimentation**: Checkpoints make it safe to try radical changes
|
||||
5. **Clean up regularly**: Delete old checkpoints to keep things organized
|
||||
6. **Combine with git**: Use checkpoints for exploration, git for finalized work
|
||||
5. **Combine with git**: Use checkpoints for exploration, git for finalized work
|
||||
6. **Summarize long sessions**: Use "Summarize from here" to keep conversations manageable
|
||||
|
||||
Reference in New Issue
Block a user