Replay Learnings surfaces relevant past lessons before you start working on a task. It searches your correction history, recalls past mistakes, and applies prior patterns — like muscle memory for your coding sessions.
Think before you act. Surface what you’ve learned before making the same mistake twice.
User: "Before I start refactoring auth, what do I know about it?"Claude: Searching learnings for 'auth', 'refactor'...REPLAY BRIEFING: auth refactor=======================Past learnings (3 found): 1. [Testing] Mock auth provider in tests, don't call live OAuth (applied 8x) Mistake: Tests were flaky due to network dependency Correction: Added jest.mock('@/lib/auth-provider') 2. [Navigation] Auth middleware is in src/middleware/auth.ts (applied 5x) Mistake: Searched in src/auth/ first, wasted time 3. [Architecture] Keep session logic in middleware, not components (applied 3x) Mistake: Put session validation in React components Correction: Moved to middleware, components just read stateSession history: - 2026-02-15: OAuth integration — 18 edits, 1 correction (5.6% rate) ✓ - 2026-01-28: Auth middleware refactor — 15 edits, 4 corrections (26.7% rate) ⚠️ ⚠️ High correction rate on Jan 28. Review what went wrong: - Forgot to mock auth provider (learning #1) - Looked in wrong directory first (learning #2) - Put logic in components instead of middleware (learning #3)Suggested approach: 1. Start in src/middleware/auth.ts (learning #2) 2. Set up test mocks first (learning #1) 3. Keep session logic in middleware (learning #3) 4. Review Jan 28 session notes for additional contextReady to proceed with this context?
User: "What do I know about GraphQL subscriptions?"Claude: Searching learnings for 'graphql', 'subscription'...REPLAY BRIEFING: GraphQL subscriptions=======================No past learnings found for this topic.Session history: - No previous work on GraphQL subscriptionsThis is new territory. Suggested approach: 1. Use scout agent to explore codebase for existing GraphQL patterns 2. Check documentation for subscription setup 3. Start with a spike/prototype approach 4. Capture learnings as you go with /learn-ruleShould I launch a scout agent to explore first?
User: "Replay learnings about database migrations"Claude: Searching learnings for 'database', 'migration'...REPLAY BRIEFING: database migrations=======================Past learnings (4 found): 1. [Quality] Always test migrations on staging data first (applied 12x) Mistake: Ran migration on prod, corrupted data Correction: Added staging migration step to runbook 2. [Git] Create migration + rollback in same commit (applied 7x) Mistake: Pushed migration without rollback, stuck when it failed Correction: Always write `up` and `down` migrations together 3. [Testing] Test migration rollback, not just forward (applied 5x) Mistake: Rollback had SQL error, couldn't revert 4. [Architecture] Never modify old migrations, create new ones (applied 4x) Mistake: Edited old migration, broke other branchesSession history: - 2026-02-28: Add user_role column — 12 edits, 0 corrections (0% rate) ✓ - 2026-02-10: Add indexes to orders — 8 edits, 1 correction (12.5% rate) ✓ - 2026-01-15: Schema refactor — 25 edits, 5 corrections (20% rate) ⚠️✓ Recent migrations went well. Pattern is working.Suggested approach: 1. Write both up and down migrations (learning #2) 2. Test rollback in local environment (learning #3) 3. Run on staging first (learning #1) 4. Don't modify existing migrations (learning #4) 5. Follow the pattern from Feb 28 session (zero corrections)Confident to proceed with migrations?
User: "What have I learned about React performance optimization?"Claude: Searching learnings for 'react', 'performance', 'optimization'...REPLAY BRIEFING: React performance optimization=======================Past learnings (5 found): 1. [Performance] Use React.memo for expensive pure components (applied 6x) Mistake: Component re-rendered on every parent update 2. [Performance] Memoize expensive computations with useMemo (applied 5x) Mistake: Recalculating on every render, caused lag 3. [Editing] Don't premature optimize, profile first (applied 4x) Mistake: Added useMemo everywhere, made code harder to read Correction: Use React DevTools Profiler to find actual bottlenecks 4. [Performance] Debounce input handlers, don't throttle (applied 3x) Mistake: Used throttle for search, felt laggy 5. [Testing] Test performance with realistic data size (applied 2x) Mistake: Tested with 10 items, prod has 10,000Session history: - 2026-03-01: Optimize table rendering — 18 edits, 5 corrections (27.8% rate) ⚠️ - 2026-02-20: Fix slow search — 12 edits, 3 corrections (25% rate) ⚠️ - 2026-02-05: Dashboard performance — 20 edits, 6 corrections (30% rate) ⚠️⚠️ HIGH CORRECTION AREA (avg 27.6% correction rate)Common mistakes in past sessions: - Optimizing without profiling first (learning #3) - Testing with small datasets (learning #5) - Over-using memoization (learning #3)Suggested approach: 1. ⚠️ PROFILE FIRST with React DevTools (learning #3) 2. Test with realistic data (learning #5) 3. Start with the highest impact optimizations 4. Apply memo/useMemo only where profiler shows benefit 5. Capture new learnings — this area needs more patternsProceed with extra caution in this area?
## Session StartBefore starting any task >5 files:1. Run replay-learnings with task keywords2. Review top 3 learnings3. Acknowledge high correction areas4. Proceed with context
# Search by keyword/search testing/search "auth middleware"# List by category/list --category Testing# Show application frequency/insights# Replay specific category/replay --category Performance
Output:
REPLAY BRIEFING: Performance category=======================All Performance learnings (8 total): 1. Use React.memo for expensive pure components (applied 6x) 2. Memoize expensive computations with useMemo (applied 5x) 3. Use indexes for frequently queried fields (applied 4x) ...