github-code/claude-howto
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

feat(uk): translate P3 examples for skills/refactor, subagents, checkpoints, advanced

Browse Source 
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
This commit is contained in:
Evgenij I
2026-04-09 22:57:13 +03:00
parent cea0a7d4ef
commit b56f1e111a
12 changed files with 2735 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

493
uk/09-advanced-features/planning-mode-examples.md Normal file
View File

@@ -0,0 +1,493 @@
# Приклади режиму планування
Реальні приклади ефективного використання режиму планування в Claude Code.
## Приклад 1: Створення REST API
### Без режиму планування
```
Користувач: Створи REST API для блогу
Claude: Створю API...
[Одразу починає кодувати, може пропустити вимоги]
```
### З режимом планування
```
Користувач: /plan Створи REST API для блогу
Claude: Створю комплексний план для API блогу.
## План реалізації REST API блогу
### Фаза 1: Налаштування проєкту (15 хв)
1. Ініціалізувати проєкт Node.js з Express
2. Налаштувати конфігурацію TypeScript
3. Встановити залежності (express, pg, jwt, joi)
4. Налаштувати змінні оточення
5. Встановити структуру проєкту
### Фаза 2: Рівень бази даних (30 хв)
6. Спроєктувати схему БД
- таблиця users (id, email, password_hash, created_at)
- таблиця posts (id, user_id, title, content, published, created_at, updated_at)
- таблиця comments (id, post_id, user_id, content, created_at)
7. Створити файли міграцій
8. Налаштувати пул зʼєднань з БД
9. Реалізувати моделі БД
### Фаза 3: Автентифікація (45 хв)
10. Реалізувати ендпоінт реєстрації
11. Реалізувати ендпоінт входу з JWT
12. Створити middleware автентифікації
13. Додати хешування паролів з bcrypt
14. Реалізувати логіку оновлення токенів
### Фаза 4: API постів (40 хв)
15. GET /api/posts — список усіх опублікованих постів (з пагінацією)
16. GET /api/posts/:id — отримати окремий пост
17. POST /api/posts — створити новий пост (потрібна автентифікація)
18. PUT /api/posts/:id — оновити пост (автентифікація, перевірка власності)
19. DELETE /api/posts/:id — видалити пост (автентифікація, перевірка власності)
20. GET /api/users/:id/posts — отримати пости користувача
### Фаза 5: API коментарів (30 хв)
21. GET /api/posts/:id/comments — отримати коментарі посту
22. POST /api/posts/:id/comments — додати коментар (потрібна автентифікація)
23. DELETE /api/comments/:id — видалити коментар (автентифікація, перевірка власності)
### Фаза 6: Валідація та обробка помилок (30 хв)
24. Додати валідацію запитів з Joi
25. Реалізувати глобальний обробник помилок
26. Додати санітизацію вхідних даних
27. Реалізувати обмеження частоти запитів
### Фаза 7: Тестування (60 хв)
28. Написати юніт-тести для моделей
29. Написати інтеграційні тести для ендпоінтів автентифікації
30. Написати інтеграційні тести для ендпоінтів постів
31. Написати інтеграційні тести для ендпоінтів коментарів
32. Досягти 80%+ покриття коду
### Фаза 8: Документація та деплой (30 хв)
33. Згенерувати API-документацію зі Swagger
34. Створити README з інструкціями налаштування
35. Додати конфігурацію Docker
36. Налаштувати CI/CD пайплайн
**Орієнтовний час**: 4.5 години
**Файлів для створення**: ~25
**Ключові технології**: Express, PostgreSQL, JWT, TypeScript
**Резюме API-ендпоінтів**:
- Автентифікація: 2 ендпоінти
- Пости: 6 ендпоінтів
- Коментарі: 3 ендпоінти
- Загалом: 11 ендпоінтів
Готові продовжити? (yes/no/modify)
Користувач: yes
Claude: Починаю Фазу 1: Налаштування проєкту...
[Реалізує кожну фазу систематично]
```
## Приклад 2: Міграція бази даних
### З режимом планування
```
Користувач: /plan Мігрувати з MongoDB на PostgreSQL
Claude: Це складна міграція. Створю детальний план.
## План міграції MongoDB → PostgreSQL
### Фаза 1: Аналіз та підготовка (День 1)
1. Проаналізувати поточну схему MongoDB
2. Визначити звʼязки та обмеження даних
3. Задокументувати поточний обсяг та темп зростання даних
4. Спроєктувати еквівалентну схему PostgreSQL
5. Спланувати відповідності типів даних
6. Визначити потенційні складнощі міграції
### Фаза 2: Налаштування PostgreSQL (День 1)
7. Налаштувати БД PostgreSQL
8. Створити схему з таблицями, індексами, обмеженнями
9. Налаштувати пул зʼєднань
10. Налаштувати стратегію резервного копіювання
### Фаза 3: Реалізація dual-write (Дні 2-3)
11. Створити рівень абстракції БД
12. Реалізувати dual-write в обидві БД
13. Додати перевірки консистентності даних
14. Деплой dual-write на staging
15. Моніторинг на предмет проблем
### Фаза 4: Міграція даних (День 4)
16. Створити скрипти експорту даних з MongoDB
17. Створити скрипти імпорту даних у PostgreSQL
18. Реалізувати логіку трансформації даних
19. Запустити початкову міграцію на копії продакшн-даних
20. Валідувати цілісність мігрованих даних
### Фаза 5: Поступове переключення (Дні 5-7)
21. Увімкнути dual-write на продакшні
22. Мігрувати історичні дані пакетами
23. Безперервно валідувати консистентність даних
24. Моніторити обидві БД
25. Виправляти проблеми синхронізації даних
### Фаза 6: PostgreSQL як основна (День 8)
26. Переключити операції читання на PostgreSQL
27. Моніторити продуктивність запитів
28. Оптимізувати повільні запити
29. Продовжити dual-write для безпеки
### Фаза 7: Виведення MongoDB (Дні 9-10)
30. Припинити запис у MongoDB
31. Залишити MongoDB як бекап на 2 тижні
32. Видалити залежності від MongoDB з коду
33. Архівувати дані MongoDB
34. Вивести з експлуатації інстанс MongoDB
**Орієнтовний час**: 10 днів
**Рівень ризику**: Високий
**Стратегія відкату**: Залишити MongoDB запущеною з dual-write
**Критерії успіху**:
- Нуль втрат даних
- <5% регресії продуктивності
- Усі тести проходять
Продовжити з цим планом? (yes/no/modify)
Користувач: Modify — додаймо план відкату для кожної фази
Claude: Оновлений план з процедурами відкату для кожної фази...
```
## Приклад 3: Рефакторинг фронтенду
```
Користувач: /plan Рефакторити React-додаток з класових компонентів на хуки
Claude: Створю систематичний план рефакторингу.
## План міграції React Class → Hooks
### Фаза 1: Підготовка та аналіз (2 години)
1. Аудит усіх класових компонентів
2. Категоризація за складністю:
- Прості (лише стан): ~15 компонентів
- Середні (методи життєвого циклу): ~23 компоненти
- Складні (кілька lifecycle, refs): ~8 компонентів
3. Визначити бібліотеки, що потребують оновлення
4. Створити граф залежностей компонентів
5. Спланувати порядок міграції (листові вузли першими)
### Фаза 2: Налаштування та інструменти (1 година)
6. Оновити React до v18+
7. Налаштувати правила ESLint для хуків
8. Створити шаблони конверсії
9. Налаштувати автоматичні тести
10. Створити контрольну точку перед початком
### Фаза 3: Міграція простих компонентів (4 години)
11. Конвертувати прості stateful компоненти (15 компонентів)
12. Замінити this.state на useState
13. Замінити this.setState на сетери стану
14. Тестувати кожен компонент після конверсії
15. Оновити тести
### Фаза 4: Міграція середніх компонентів (8 годин)
16. Конвертувати компоненти з методами lifecycle (23 компоненти)
17. Замінити componentDidMount на useEffect
18. Замінити componentDidUpdate на useEffect
19. Замінити componentWillUnmount на очищення useEffect
20. Ретельно тестувати
### Фаза 5: Міграція складних компонентів (12 годин)
21. Конвертувати складні компоненти (8 компонентів)
22. Замінити refs на useRef
23. Витягти кастомні хуки для спільної логіки
24. Обробити крайні випадки (кілька useEffect)
25. Розширене тестування
### Фаза 6: Витяг спільної логіки (6 годин)
26. Виявити дубльовану логіку між компонентами
27. Створити кастомні хуки:
- useAuth
- useFetch
- useLocalStorage
- useDebounce
28. Рефакторити компоненти для використання кастомних хуків
29. Тестувати кастомні хуки незалежно
### Фаза 7: Оптимізація продуктивності (4 години)
30. Додати React.memo де потрібно
31. Оптимізувати з useCallback
32. Оптимізувати з useMemo
33. Профілювати та виправити регресії продуктивності
### Фаза 8: Очищення та документація (2 години)
34. Видалити невикористані утиліти класових компонентів
35. Оновити документацію
36. Оновити рекомендації з кодування
37. Створити посібник міграції для команди
**Орієнтовний час**: 5 днів (39 годин)
**Файлів для зміни**: 46 компонентів
**Рівень ризику**: Середній
**Порядок міграції**:
1. Листові компоненти (без залежностей)
2. Компоненти середнього рівня
3. Контейнерні компоненти верхнього рівня
4. App.jsx (останній)
Продовжити? (yes/no/modify)
```
## Приклад 4: Реалізація безпеки
```
Користувач: /plan Реалізувати комплексну безпеку для нашого веб-додатку
Claude: Створю ретельний план реалізації безпеки.
## План реалізації безпеки веб-додатку
### Фаза 1: Аудит безпеки (День 1)
1. Запустити автоматичні сканери безпеки (npm audit, Snyk)
2. Перевірити залежності на вразливості
3. Перевірити відповідність OWASP Top 10
4. Аудит потоків автентифікації
5. Перевірити практики обробки даних
6. Задокументувати поточні прогалини безпеки
### Фаза 2: Посилення автентифікації (Дні 2-3)
7. Реалізувати вимоги до складності паролів
8. Додати індикатор надійності пароля
9. Реалізувати обмеження частоти спроб входу
10. Додати блокування облікового запису після невдалих спроб
11. Реалізувати 2FA (TOTP)
12. Покращити управління сесіями
13. Реалізувати безпечний потік скидання пароля
### Фаза 3: Авторизація та контроль доступу (Дні 3-4)
14. Реалізувати RBAC (контроль доступу на основі ролей)
15. Додати перевірки дозволів на всіх ендпоінтах
16. Реалізувати принцип мінімальних привілеїв
17. Додати журнал аудиту для чутливих операцій
18. Реалізувати дозволи на рівні ресурсів
### Фаза 4: Захист даних (Дні 4-5)
19. Реалізувати шифрування в стані спокою (чутливі поля)
20. Забезпечити TLS/SSL для всіх комунікацій
21. Реалізувати безпечне зберігання сесій
22. Додати маскування PII у журналах
23. Реалізувати політики збереження даних
24. Додати безпечну обробку завантаження файлів
### Фаза 5: Валідація та санітизація введення (Дні 5-6)
25. Реалізувати валідацію введення на всіх ендпоінтах
26. Додати захист від XSS (Content Security Policy)
27. Реалізувати захист від SQL-інʼєкцій (параметризовані запити)
28. Додати захист від CSRF
29. Реалізувати ліміти розміру запитів
30. Додати валідацію типів файлів при завантаженні
### Фаза 6: Заголовки безпеки та конфігурація (День 6)
31. Додати заголовки безпеки:
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options
- X-XSS-Protection
- Content-Security-Policy
32. Правильно налаштувати CORS
33. Вимкнути непотрібні HTTP-методи
34. Видалити заголовки версії сервера
### Фаза 7: Моніторинг та логування (День 7)
35. Реалізувати логування подій безпеки
36. Додати виявлення аномалій
37. Налаштувати виявлення вторгнень
38. Реалізувати алертинг у реальному часі
39. Створити дашборд безпеки
### Фаза 8: Тестування та документація (Дні 8-9)
40. Провести тестування на проникнення
41. Запустити сканери безпеки
42. Протестувати всі функції безпеки
43. Створити документацію безпеки
44. Навчити команду практикам безпеки
45. Створити план реагування на інциденти
### Фаза 9: Відповідність та політики (День 10)
46. Перевірка відповідності GDPR
47. Створити політику конфіденційності
48. Реалізувати права субʼєктів даних
49. Додати згоду на cookies
50. Створити документацію політик безпеки
**Орієнтовний час**: 10 днів
**Рівень ризику**: Критичний
**Пріоритет**: Високий
**Відповідність**: OWASP Top 10, GDPR
Продовжити? (yes/no/modify)
```
## Приклад 5: Оптимізація продуктивності
```
Користувач: /plan Оптимізувати наш повільний сайт електронної комерції
Claude: Створю комплексний план оптимізації продуктивності.
## План оптимізації продуктивності електронної комерції
### Фаза 1: Аудит продуктивності (4 години)
1. Запустити аудит Lighthouse
2. Проаналізувати профіль продуктивності Chrome DevTools
3. Виміряти Core Web Vitals:
- LCP (Largest Contentful Paint)
- FID (First Input Delay)
- CLS (Cumulative Layout Shift)
4. Визначити вузькі місця продуктивності
5. Створити базові метрики продуктивності
**Поточні метрики**:
- LCP: 4.2с (ціль: <2.5с)
- FID: 280мс (ціль: <100мс)
- CLS: 0.25 (ціль: <0.1)
- Завантаження сторінки: 8.3с (ціль: <3с)
### Фаза 2: Оптимізація зображень (6 годин)
6. Конвертувати зображення у формат WebP
7. Реалізувати адаптивні зображення
8. Додати ліниве завантаження зображень
9. Оптимізувати розміри зображень (стиснення)
10. Реалізувати CDN для зображень
11. Додати плейсхолдери зображень
**Очікуваний вплив**: -40% час завантаження
### Фаза 3: Розділення коду та ліниве завантаження (8 годин)
12. Реалізувати розділення коду за маршрутами
13. Ліниво завантажувати некритичні компоненти
14. Розділити vendor-бандли
15. Оптимізувати розміри чанків
16. Реалізувати динамічні імпорти
17. Додати попереднє завантаження критичних ресурсів
**Очікуваний вплив**: -30% початковий розмір бандлу
### Фаза 4: Стратегія кешування (6 годин)
18. Реалізувати кешування браузером (Cache-Control)
19. Додати service worker для офлайн-підтримки
20. Реалізувати кешування відповідей API
21. Додати кеш Redis для запитів до БД
22. Реалізувати stale-while-revalidate
23. Налаштувати кешування CDN
**Очікуваний вплив**: -50% час відповіді API
### Фаза 5: Оптимізація БД (8 годин)
24. Додати індекси в БД
25. Оптимізувати повільні запити (>100мс)
26. Реалізувати кешування результатів запитів
27. Додати пул зʼєднань
28. Денормалізувати де доречно
29. Реалізувати репліки БД для читання
**Очікуваний вплив**: -60% час запитів до БД
### Фаза 6: Оптимізація фронтенду (10 годин)
30. Мінімізувати та стиснути JavaScript
31. Мінімізувати та стиснути CSS
32. Видалити невикористаний CSS (PurgeCSS)
33. Реалізувати критичний CSS
34. Відкласти некритичний JavaScript
35. Зменшити розмір DOM
36. Оптимізувати рендеринг React (memo, useMemo)
37. Реалізувати віртуальний скролінг для довгих списків
**Очікуваний вплив**: -35% час виконання JavaScript
### Фаза 7: Оптимізація мережі (4 години)
38. Увімкнути HTTP/2
39. Реалізувати підказки ресурсів (preconnect, prefetch)
40. Зменшити кількість HTTP-запитів
41. Увімкнути стиснення Brotli
42. Оптимізувати сторонні скрипти
**Очікуваний вплив**: -25% мережевий час
### Фаза 8: Моніторинг та тестування (4 години)
43. Налаштувати моніторинг продуктивності (Datadog/New Relic)
44. Додати Real User Monitoring (RUM)
45. Створити бюджети продуктивності
46. Налаштувати автоматичний Lighthouse CI
47. Тестувати на реальних пристроях
**Орієнтовний час**: 50 годин (2 тижні)
**Цільові метрики** (90-й перцентиль):
- LCP: <2.0с (з 4.2с) ✅
- FID: <50мс (з 280мс) ✅
- CLS: <0.05 (з 0.25) ✅
- Завантаження: <2.5с (з 8.3с) ✅
**Порядок пріоритету**:
1. Оптимізація зображень (швидкі перемоги)
2. Розділення коду (високий вплив)
3. Кешування (високий вплив)
4. Оптимізація БД (критично)
5. Оптимізація фронтенду (полірування)
Продовжити з цим планом? (yes/no/modify)
```
## Ключові висновки
### Переваги режиму планування
1. **Ясність**: Чіткий план дій перед початком
2. **Оцінка**: Оцінки часу та зусиль
3. **Оцінка ризиків**: Раннє виявлення потенційних проблем
4. **Пріоритезація**: Логічний порядок завдань
5. **Затвердження**: Перегляд та затвердження перед виконанням
6. **Модифікація**: Коригування плану на основі зворотного звʼязку
### Коли використовувати режим планування
✅ **Завжди використовуйте для**:
- Багатоденних проєктів
- Командних співпраць
- Критичних змін системи
- Вивчення нових концепцій
- Складного рефакторингу
❌ **Не використовуйте для**:
- Виправлення помилок
- Дрібних правок
- Простих запитань
- Швидких експериментів
### Найкращі практики
1. **Ретельно переглядайте плани** перед затвердженням
2. **Модифікуйте плани**, коли помічаєте проблеми
3. **Розбивайте** складні завдання
4. **Оцінюйте реалістичні** часові рамки
5. **Включайте стратегії відкату**
6. **Додавайте критерії успіху**
7. **Плануйте тестування** на кожній фазі
---
**Останнє оновлення**: 9 квітня 2026