03-skills/refactor: SKILL.md + templates/refactoring-plan.md 04-subagents: 8 agent definitions 08-checkpoints: checkpoint-examples.md 09-advanced: planning-mode-examples.md Remaining: refactor references (1692 lines), P4 root docs Ref: luongnv89/claude-howto#63
16 KiB
Приклади контрольних точок
Реальні приклади ефективного використання контрольних точок у Claude Code.
Примітка: Контрольні точки створюються автоматично з кожним промптом користувача. Вам не потрібно зберігати їх вручну. Для відкату натисніть Esc двічі (Esc+Esc) або використовуйте /rewind для відкриття браузера контрольних точок.
Приклад 1: Міграція бази даних
Сценарій
Потрібно мігрувати з MySQL на PostgreSQL, але хочете дослідити як пряму міграцію, так і поступовий підхід з подвійним записом (dual-write).
Робочий процес
Користувач: Реалізуймо пряму міграцію з MySQL на PostgreSQL
[Контрольна точка A створена автоматично]
Claude: Реалізую пряму міграцію...
[Змінює драйвер БД, оновлює запити, модифікує схему]
Користувач: Запусти тести
[Контрольна точка B створена автоматично]
Claude: Запускаю тести...
❌ 15 тестів не проходять — проблеми з пулом зʼєднань
Користувач: Цей підхід має проблеми. Спробуймо патерн dual-write.
[Користувач натискає Esc+Esc, обирає контрольну точку A, обирає "Restore code and conversation"]
Користувач: Тепер реалізуй патерн dual-write, де ми пишемо в обидві БД
Claude: Реалізую міграцію з dual-write...
[Реалізує рівень dual-write, стратегію поступової міграції]
Користувач: Запусти тести
Claude: Запускаю тести...
✅ Усі тести проходять
Користувач: Підхід dual-write явно безпечніший. Закомітимо це.
Приклад 2: Оптимізація продуктивності
Сценарій
Кілька стратегій оптимізації продуктивності для випробування.
Робочий процес
Користувач: Оптимізуймо час відповіді API. Поточний: 450мс
[Контрольна точка "Baseline" створена автоматично]
Claude: Додам кешування запитів до БД...
[Реалізує кешування Redis]
Користувач: Запусти тести продуктивності
Claude: Результати: 280мс середній час відповіді (покращення 38%)
Користувач: Спробую інший підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Baseline", обирає "Restore code and conversation"]
Користувач: Спробуй оптимізацію запитів до БД
Claude: Оптимізую запити до БД...
[Додає індекси, оптимізує N+1 запити]
Користувач: Запусти тести продуктивності
Claude: Результати: 180мс середній час відповіді (покращення 60%)
Користувач: Спробую ще третій підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Baseline", обирає "Restore code and conversation"]
Користувач: Спробуй стиснення відповідей та CDN
Claude: Додам стиснення та CDN...
[Реалізує gzip, налаштовує CDN]
Користувач: Запусти тести продуктивності
Claude: Результати: 320мс середній час відповіді (покращення 29%)
Користувач: Оптимізація запитів була найкращою. Повернуся та поєднаю з кешуванням.
[Користувач натискає Esc+Esc, обирає контрольну точку після оптимізації запитів, обирає "Restore code and conversation"]
Користувач: Тепер додай кешування Redis поверх цих оптимізованих запитів
Claude: [Додає кешування Redis поверх оптимізованих запитів]
Користувач: Запусти тести продуктивності
Claude: Результати: 95мс середній час відповіді (покращення 79%) 🎉
Користувач: Ідеально! Це переможець. Закомітимо.
Приклад 3: Ітерація UI/UX
Сценарій
Випробування різних макетів для дашборду.
Робочий процес
Користувач: Перепроєктуймо дашборд з бічною панеллю
[Контрольна точка "Start" створена автоматично]
Claude: [Реалізує макет з бічною панеллю]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Бічна панель тісна. Спробуймо верхню навігацію.
[Користувач натискає Esc+Esc, обирає контрольну точку "Start", обирає "Restore code and conversation"]
Користувач: Спробуй макет з верхньою навігацією
Claude: [Реалізує верхню навігацію]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Краще, але спробуймо макет у вигляді сітки карток
[Користувач натискає Esc+Esc, обирає контрольну точку "Start", обирає "Restore code and conversation"]
Користувач: Спробуй макет сітки карток
Claude: [Реалізує сітку карток]
Користувач: Покажи скріншот
Claude: [Показує скріншот]
Користувач: Чудово! Але чи можемо поєднати верхню навігацію із сіткою карток?
[Користувач натискає Esc+Esc, обирає контрольну точку після сітки карток, обирає "Restore code and conversation"]
Користувач: Додай верхню навігацію до макету сітки карток
Claude: [Додає верхню навігацію до сітки карток]
Користувач: Ідеально! Це фінальний дизайн.
Приклад 4: Сесія налагодження
Сценарій
Полювання на складну помилку з кількома гіпотезами.
Робочий процес
Користувач: В додатку є витік памʼяті
[Контрольна точка "Before debugging" створена автоматично]
Claude: Досліджую...
[Аналізує код]
Користувач: Думаю, це в обробниках подій. Виправимо їх.
Claude: [Виправляє очищення обробників подій]
Користувач: Запусти профілювальник памʼяті
Claude: Памʼять все ще тече — обробники подій не були причиною
Користувач: Повернуся та спробую іншу гіпотезу.
[Користувач натискає Esc+Esc, обирає контрольну точку "Before debugging", обирає "Restore code and conversation"]
Користувач: Може це зʼєднання з БД?
Claude: [Реалізує виправлення пулу зʼєднань]
Користувач: Запусти профілювальник памʼяті
Claude: Все ще тече — не зʼєднання
Користувач: Повернуся та спробую інший ракурс.
[Користувач натискає Esc+Esc, обирає контрольну точку "Before debugging", обирає "Restore code and conversation"]
Користувач: Перевіримо циклічні посилання
Claude: [Знаходить та виправляє циклічні посилання в кеші]
Користувач: Запусти профілювальник памʼяті
Claude: ✅ Витік памʼяті виправлено! Циклічні посилання в рівні кешування були причиною.
Користувач: Відмінно! Закомітимо це виправлення.
Приклад 5: Еволюція дизайну API
Сценарій
Проєктування REST API з кількома ітераціями.
Робочий процес
Користувач: Створи REST API для нашої блог-платформи
[Контрольна точка "Before API design" створена автоматично]
Claude: [Створює базовий CRUD API]
Користувач: Це занадто просто. Додаймо пагінацію та фільтрацію
Claude: [Додає пагінацію та фільтрацію]
Користувач: Потрібні кращі звʼязки між ресурсами
Claude: [Реалізує HATEOAS-посилання]
Користувач: Власне, спробуймо GraphQL замість REST
[Користувач натискає Esc+Esc, обирає контрольну точку "Before API design", обирає "Restore code and conversation"]
Користувач: Реалізуй GraphQL API для нашої блог-платформи
Claude: [Реалізує GraphQL API]
Користувач: Думаю, REST краще для нашого випадку.
[Користувач натискає Esc+Esc, обирає контрольну точку після HATEOAS, обирає "Restore code and conversation"]
Користувач: Фіналізуємо REST-підхід.
Приклад 6: Управління конфігурацією
Сценарій
Тестування різних підходів до конфігурації.
Робочий процес
Користувач: Перемісти конфігурацію у змінні оточення
[Контрольна точка "Original config" створена автоматично]
Claude: [Реалізує конфігурацію через змінні оточення]
Користувач: Тест у середовищі розробки
Claude: Працює локально, але проблеми з деплоєм на продакшні
Користувач: Спробую інший підхід.
[Користувач натискає Esc+Esc, обирає контрольну точку "Original config", обирає "Restore code and conversation"]
Користувач: Спробуй підхід з файлом конфігурації та валідацією
Claude: [Реалізує YAML-конфігурацію з валідацією JSON Schema]
Користувач: Тест у середовищі розробки
Claude: ✅ Працює добре, хороші повідомлення про помилки валідації
Користувач: Чи можемо також підтримувати змінні оточення для чутливих значень?
Claude: [Додає перевизначення через змінні оточення для секретів]
Користувач: Тест деплою
Claude: ✅ Усі середовища працюють коректно
Користувач: Ідеально! Це готове для продакшну.
Приклад 7: Стратегія тестування
Сценарій
Реалізація комплексного тестування.
Робочий процес
Користувач: Додай юніт-тести для модуля автентифікації
[Контрольна точка створена автоматично]
Claude: [Додає юніт-тести Jest]
Користувач: Запусти тести
Claude: 45 тестів проходять, 78% покриття
Користувач: Додай також інтеграційні тести
Claude: [Додає інтеграційні тести]
Користувач: Запусти тести
Claude: 89 тестів проходять, 92% покриття, але тести повільні (3 хвилини)
Користувач: Тести занадто повільні. Оптимізуймо.
Claude: [Оптимізує налаштування тестів, додає паралельне виконання]
Користувач: Запусти тести
Claude: 89 тестів проходять, 92% покриття, 35 секунд ✅
Користувач: Чудово! Тепер додай E2E тести для критичних шляхів
Claude: [Додає E2E тести Playwright]
Користувач: Запусти всі тести
Claude: 112 тестів проходять, 94% покриття, 2 хвилини
Користувач: Ідеальний баланс покриття та швидкості!
Приклад 8: Використання підсумку від контрольної точки
Сценарій
Після довгої сесії налагодження хочете стиснути розмову, зберігаючи контекст.
Робочий процес
Користувач: [Після 20+ повідомлень налагодження та дослідження]
[Користувач натискає Esc+Esc, обирає ранню контрольну точку, обирає "Summarize from here"]
[Необовʼязково надає інструкції: "Зосередься на тому, що ми спробували і що спрацювало"]
Claude: [Генерує підсумок розмови від цієї точки далі]
[Оригінальні повідомлення зберігаються в транскрипті]
[Підсумок замінює видиму розмову, зменшуючи використання контекстного вікна]
Користувач: Тепер продовжимо з підходом, що спрацював.
Ключові висновки
- Контрольні точки автоматичні: Кожен промпт користувача створює контрольну точку — ручне збереження не потрібне
- Використовуйте Esc+Esc або /rewind: Два способи доступу до браузера контрольних точок
- Обирайте правильний варіант відновлення: Відновити код, розмову, обидва або підсумувати — залежно від потреб
- Не бійтеся експериментувати: Контрольні точки роблять безпечним випробування радикальних змін
- Поєднуйте з git: Контрольні точки для дослідження, git для фіналізованої роботи
- Підсумовуйте довгі сесії: Використовуйте "Summarize from here" для підтримки керованості розмов
Останнє оновлення: 9 квітня 2026