feat(uk): translate P3 examples for modules 01, 02
01-slash-commands: 7 slash command examples 02-memory: 3 CLAUDE.md examples Progress: 25/67 files Ref: luongnv89/claude-howto#63
This commit is contained in:
Evgenij I
29
uk/01-slash-commands/commit.md
Normal file
29
uk/01-slash-commands/commit.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*)
|
||||
argument-hint: [message]
|
||||
description: Створити git-коміт з контекстом
|
||||
---
|
||||
|
||||
## Контекст
|
||||
|
||||
- Поточний статус git: !`git status`
|
||||
- Поточний git diff: !`git diff HEAD`
|
||||
- Поточна гілка: !`git branch --show-current`
|
||||
- Останні коміти: !`git log --oneline -10`
|
||||
|
||||
## Ваше завдання
|
||||
|
||||
На основі наведених вище змін створіть один git-коміт.
|
||||
|
||||
Якщо повідомлення було передано через аргументи, використовуйте його: $ARGUMENTS
|
||||
|
||||
Інакше проаналізуйте зміни та створіть відповідне повідомлення коміту відповідно до формату conventional commits:
|
||||
- `feat:` для нових функцій
|
||||
- `fix:` для виправлення помилок
|
||||
- `docs:` для змін документації
|
||||
- `refactor:` для рефакторингу коду
|
||||
- `test:` для додавання тестів
|
||||
- `chore:` для задач обслуговування
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
27
uk/01-slash-commands/doc-refactor.md
Normal file
27
uk/01-slash-commands/doc-refactor.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
name: Documentation Refactor
|
||||
description: Реструктуризація документації проєкту для ясності та доступності
|
||||
tags: documentation, refactoring, organization
|
||||
---
|
||||
|
||||
# Рефакторинг документації
|
||||
|
||||
Рефакторинг структури документації проєкту з адаптацією до типу проєкту:
|
||||
|
||||
1. **Аналіз проєкту**: Визначити тип (бібліотека/API/веб-додаток/CLI/мікросервіси), архітектуру та персони користувачів
|
||||
2. **Централізація документації**: Перемістити технічну документацію до `docs/` з належними перехресними посиланнями
|
||||
3. **Кореневий README.md**: Оптимізувати як точку входу з оглядом, швидким стартом, резюме модулів/компонентів, ліцензією, контактами
|
||||
4. **Документація компонентів**: Додати README файли на рівні модулів/пакетів/сервісів з інструкціями налаштування та тестування
|
||||
5. **Організація `docs/`** за відповідними категоріями:
|
||||
- Архітектура, Довідник API, База даних, Дизайн, Усунення несправностей, Деплой, Контрибʼюція (адаптувати до потреб проєкту)
|
||||
6. **Створення посібників** (оберіть застосовні):
|
||||
- Посібник користувача: Документація для кінцевих користувачів додатків
|
||||
- Документація API: Ендпоінти, автентифікація, приклади для API
|
||||
- Посібник розробника: Налаштування, тестування, процес контрибʼюції
|
||||
- Посібник деплою: Деплой на продакшн для сервісів/додатків
|
||||
7. **Використання Mermaid** для всіх діаграм (архітектура, потоки, схеми)
|
||||
|
||||
Тримайте документацію лаконічною, зручною для сканування та контекстно відповідною типу проєкту.
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
22
uk/01-slash-commands/generate-api-docs.md
Normal file
22
uk/01-slash-commands/generate-api-docs.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: Створення вичерпної документації API з вихідного коду
|
||||
---
|
||||
|
||||
# Генератор документації API
|
||||
|
||||
Генерація документації API шляхом:
|
||||
|
||||
1. Сканування всіх файлів у `/src/api/`
|
||||
2. Витягу сигнатур функцій та коментарів JSDoc
|
||||
3. Організації за ендпоінтом/модулем
|
||||
4. Створення markdown з прикладами
|
||||
5. Включення схем запитів/відповідей
|
||||
6. Додавання документації помилок
|
||||
|
||||
Формат виводу:
|
||||
- Markdown-файл у `/docs/api.md`
|
||||
- Включити приклади curl для всіх ендпоінтів
|
||||
- Додати типи TypeScript
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
22
uk/01-slash-commands/optimize.md
Normal file
22
uk/01-slash-commands/optimize.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: Аналіз коду на проблеми продуктивності та пропозиції оптимізацій
|
||||
---
|
||||
|
||||
# Оптимізація коду
|
||||
|
||||
Перегляньте наданий код на наявність таких проблем у порядку пріоритету:
|
||||
|
||||
1. **Вузькі місця продуктивності** — виявлення операцій O(n²), неефективних циклів
|
||||
2. **Витоки памʼяті** — пошук невивільнених ресурсів, циклічних посилань
|
||||
3. **Покращення алгоритмів** — пропозиція кращих алгоритмів або структур даних
|
||||
4. **Можливості кешування** — виявлення повторюваних обчислень
|
||||
5. **Проблеми конкурентності** — пошук станів гонки (race conditions) або проблем з потоками
|
||||
|
||||
Формат відповіді:
|
||||
- Серйозність проблеми (Критична/Висока/Середня/Низька)
|
||||
- Місце в коді
|
||||
- Пояснення
|
||||
- Рекомендоване виправлення з прикладом коду
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
29
uk/01-slash-commands/pr.md
Normal file
29
uk/01-slash-commands/pr.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
description: Очистити код, підготувати зміни та створити pull request
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(npm test:*), Bash(npm run lint:*)
|
||||
---
|
||||
|
||||
# Контрольний список підготовки Pull Request
|
||||
|
||||
Перед створенням PR виконайте ці кроки:
|
||||
|
||||
1. Запустити лінтинг: `prettier --write .`
|
||||
2. Запустити тести: `npm test`
|
||||
3. Переглянути git diff: `git diff HEAD`
|
||||
4. Додати зміни до індексу: `git add .`
|
||||
5. Створити повідомлення коміту відповідно до conventional commits:
|
||||
- `fix:` для виправлення помилок
|
||||
- `feat:` для нових функцій
|
||||
- `docs:` для документації
|
||||
- `refactor:` для реструктуризації коду
|
||||
- `test:` для додавання тестів
|
||||
- `chore:` для обслуговування
|
||||
|
||||
6. Згенерувати опис PR, що включає:
|
||||
- Що змінилося
|
||||
- Чому змінилося
|
||||
- Проведене тестування
|
||||
- Потенційні наслідки
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
155
uk/01-slash-commands/push-all.md
Normal file
155
uk/01-slash-commands/push-all.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
description: Додати всі зміни до індексу, створити коміт та відправити на віддалений сервер (використовуйте з обережністю)
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git push:*), Bash(git diff:*), Bash(git log:*), Bash(git pull:*)
|
||||
---
|
||||
|
||||
# Коміт та Push усього
|
||||
|
||||
⚠️ **УВАГА**: Додає ВСІ зміни до індексу, створює коміт та відправляє на віддалений сервер. Використовуйте лише коли впевнені, що всі зміни належать разом.
|
||||
|
||||
## Робочий процес
|
||||
|
||||
### 1. Аналіз змін
|
||||
Запустити паралельно:
|
||||
- `git status` — показати змінені/додані/видалені/невідстежувані файли
|
||||
- `git diff --stat` — показати статистику змін
|
||||
- `git log -1 --oneline` — показати останній коміт для стилю повідомлення
|
||||
|
||||
### 2. Перевірки безпеки
|
||||
|
||||
**❌ ЗУПИНИТИ та ПОПЕРЕДИТИ при виявленні:**
|
||||
- Секрети: `.env*`, `*.key`, `*.pem`, `credentials.json`, `secrets.yaml`, `id_rsa`, `*.p12`, `*.pfx`, `*.cer`
|
||||
- API-ключі: Будь-які змінні `*_API_KEY`, `*_SECRET`, `*_TOKEN` з реальними значеннями (не заповнювачі типу `your-api-key`, `xxx`, `placeholder`)
|
||||
- Великі файли: `>10MB` без Git LFS
|
||||
- Артефакти збірки: `node_modules/`, `dist/`, `build/`, `__pycache__/`, `*.pyc`, `.venv/`
|
||||
- Тимчасові файли: `.DS_Store`, `thumbs.db`, `*.swp`, `*.tmp`
|
||||
|
||||
**Валідація API-ключів:**
|
||||
Перевірити змінені файли на патерни:
|
||||
```bash
|
||||
OPENAI_API_KEY=sk-proj-xxxxx # ❌ Виявлено реальний ключ!
|
||||
AWS_SECRET_KEY=AKIA... # ❌ Виявлено реальний ключ!
|
||||
STRIPE_API_KEY=sk_live_... # ❌ Виявлено реальний ключ!
|
||||
|
||||
# ✅ Допустимі заповнювачі:
|
||||
API_KEY=your-api-key-here
|
||||
SECRET_KEY=placeholder
|
||||
TOKEN=xxx
|
||||
API_KEY=<your-key>
|
||||
SECRET=${YOUR_SECRET}
|
||||
```
|
||||
|
||||
**✅ Перевірити:**
|
||||
- `.gitignore` правильно налаштований
|
||||
- Немає конфліктів злиття
|
||||
- Правильна гілка (попередити якщо main/master)
|
||||
- API-ключі є лише заповнювачами
|
||||
|
||||
### 3. Запит підтвердження
|
||||
|
||||
Представити резюме:
|
||||
```
|
||||
📊 Резюме змін:
|
||||
- X файлів змінено, Y додано, Z видалено
|
||||
- Загалом: +AAA вставок, -BBB видалень
|
||||
|
||||
🔒 Безпека: ✅ Без секретів | ✅ Без великих файлів | ⚠️ [попередження]
|
||||
🌿 Гілка: [назва] → origin/[назва]
|
||||
|
||||
Я виконаю: git add . → commit → push
|
||||
|
||||
Введіть 'yes' для продовження або 'no' для скасування.
|
||||
```
|
||||
|
||||
**ЧЕКАТИ явного "yes" перед продовженням.**
|
||||
|
||||
### 4. Виконання (після підтвердження)
|
||||
|
||||
Запустити послідовно:
|
||||
```bash
|
||||
git add .
|
||||
git status # Перевірка індексу
|
||||
```
|
||||
|
||||
### 5. Генерація повідомлення коміту
|
||||
|
||||
Проаналізувати зміни та створити conventional commit:
|
||||
|
||||
**Формат:**
|
||||
```
|
||||
[тип]: Короткий опис (макс. 72 символи)
|
||||
|
||||
- Ключова зміна 1
|
||||
- Ключова зміна 2
|
||||
- Ключова зміна 3
|
||||
```
|
||||
|
||||
**Типи:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf`, `build`, `ci`
|
||||
|
||||
**Приклад:**
|
||||
```
|
||||
docs: Update concept README files with comprehensive documentation
|
||||
|
||||
- Add architecture diagrams and tables
|
||||
- Include practical examples
|
||||
- Expand best practices sections
|
||||
```
|
||||
|
||||
### 6. Коміт та Push
|
||||
|
||||
```bash
|
||||
git commit -m "$(cat <<'EOF'
|
||||
[Згенероване повідомлення коміту]
|
||||
EOF
|
||||
)"
|
||||
git push # Якщо невдача: git pull --rebase && git push
|
||||
git log -1 --oneline --decorate # Перевірка
|
||||
```
|
||||
|
||||
### 7. Підтвердження успіху
|
||||
|
||||
```
|
||||
✅ Успішно відправлено на віддалений сервер!
|
||||
|
||||
Коміт: [хеш] [повідомлення]
|
||||
Гілка: [гілка] → origin/[гілка]
|
||||
Змінено файлів: X (+вставок, -видалень)
|
||||
```
|
||||
|
||||
## Обробка помилок
|
||||
|
||||
- **git add невдача**: Перевірити дозволи, заблоковані файли, переконатися що репо ініціалізовано
|
||||
- **git commit невдача**: Виправити pre-commit хуки, перевірити git config (user.name/email)
|
||||
- **git push невдача**:
|
||||
- Non-fast-forward: `git pull --rebase && git push`
|
||||
- Немає віддаленої гілки: `git push -u origin [гілка]`
|
||||
- Захищена гілка: Використати PR-процес замість цього
|
||||
|
||||
## Коли використовувати
|
||||
|
||||
✅ **Доцільно:**
|
||||
- Оновлення документації в кількох файлах
|
||||
- Функція з тестами та документацією
|
||||
- Виправлення помилок у кількох файлах
|
||||
- Форматування/рефакторинг всього проєкту
|
||||
- Зміни конфігурації
|
||||
|
||||
❌ **Уникати:**
|
||||
- Невпевненість у тому, що комітиться
|
||||
- Містить секрети/чутливі дані
|
||||
- Захищені гілки без рев'ю
|
||||
- Присутні конфлікти злиття
|
||||
- Потрібна гранулярна історія комітів
|
||||
- Pre-commit хуки не проходять
|
||||
|
||||
## Альтернативи
|
||||
|
||||
Якщо користувач хоче більше контролю, запропонувати:
|
||||
1. **Вибіркове додавання**: Переглянути/додати конкретні файли
|
||||
2. **Інтерактивне додавання**: `git add -p` для вибору патчів
|
||||
3. **PR-процес**: Створити гілку → push → PR (використати команду `/pr`)
|
||||
|
||||
**⚠️ Памʼятайте**: Завжди переглядайте зміни перед push. Якщо сумніваєтесь, використовуйте окремі git-команди для більшого контролю.
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
28
uk/01-slash-commands/setup-ci-cd.md
Normal file
28
uk/01-slash-commands/setup-ci-cd.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: Setup CI/CD Pipeline
|
||||
description: Реалізація pre-commit хуків та GitHub Actions для забезпечення якості
|
||||
tags: ci-cd, devops, automation
|
||||
---
|
||||
|
||||
# Налаштування CI/CD пайплайну
|
||||
|
||||
Реалізація комплексних шлюзів якості DevOps з адаптацією до типу проєкту:
|
||||
|
||||
1. **Аналіз проєкту**: Визначити мову(и), фреймворк, систему збірки та наявний інструментарій
|
||||
2. **Налаштування pre-commit хуків** з інструментами для конкретної мови:
|
||||
- Форматування: Prettier/Black/gofmt/rustfmt/тощо
|
||||
- Лінтинг: ESLint/Ruff/golangci-lint/Clippy/тощо
|
||||
- Безпека: Bandit/gosec/cargo-audit/npm audit/тощо
|
||||
- Перевірка типів: TypeScript/mypy/flow (якщо застосовно)
|
||||
- Тести: Запуск відповідних тестових наборів
|
||||
3. **Створення GitHub Actions workflows** (.github/workflows/):
|
||||
- Дзеркалювання pre-commit перевірок на push/PR
|
||||
- Матриця версій/платформ (якщо застосовно)
|
||||
- Верифікація збірки та тестів
|
||||
- Кроки деплою (за потреби)
|
||||
4. **Верифікація пайплайну**: Тестування локально, створення тестового PR, підтвердження проходження всіх перевірок
|
||||
|
||||
Використовуйте безкоштовні/відкриті інструменти. Поважайте існуючі конфігурації. Тримайте виконання швидким.
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
28
uk/01-slash-commands/unit-test-expand.md
Normal file
28
uk/01-slash-commands/unit-test-expand.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
name: Expand Unit Tests
|
||||
description: Збільшення покриття тестами шляхом тестування невідстежених гілок та граничних випадків
|
||||
tags: testing, coverage, unit-tests
|
||||
---
|
||||
|
||||
# Розширення юніт-тестів
|
||||
|
||||
Розширення існуючих юніт-тестів з адаптацією до тестового фреймворку проєкту:
|
||||
|
||||
1. **Аналіз покриття**: Запустити звіт покриття для виявлення неперевірених гілок, граничних випадків та зон з низьким покриттям
|
||||
2. **Виявлення прогалин**: Переглянути код на предмет логічних гілок, шляхів помилок, граничних умов, null/порожніх вхідних даних
|
||||
3. **Написання тестів** з використанням фреймворку проєкту:
|
||||
- Jest/Vitest/Mocha (JavaScript/TypeScript)
|
||||
- pytest/unittest (Python)
|
||||
- Go testing/testify (Go)
|
||||
- Rust test framework (Rust)
|
||||
4. **Цільові сценарії**:
|
||||
- Обробка помилок та виключень
|
||||
- Граничні значення (мін/макс, порожні, null)
|
||||
- Крайні та кутові випадки (edge/corner cases)
|
||||
- Переходи станів та побічні ефекти
|
||||
5. **Верифікація покращення**: Запустити покриття повторно, підтвердити вимірюване збільшення
|
||||
|
||||
Представляти лише нові блоки тестового коду. Дотримуватися існуючих патернів та конвенцій іменування тестів.
|
||||
|
||||
---
|
||||
**Останнє оновлення**: 9 квітня 2026
|
||||
Reference in New Issue
Block a user