Save this content to: .claude/skills/plan/SKILL.md

# Skill: Plan (Planning)

**Версия:** 2026‑02‑02

Эта skill нужна, чтобы **превратить размытый запрос в чёткий инженерный план**, как делает сильный синьор: с вариантами, рисками, критическими деталями и понятной последовательностью шагов.

> ⚠️ **Ограничение:** эта skill **только для жёсткого агента / deep‑аналитика** (например `laravel-senior-analyst`). Если ты работаешь в режиме «минимальные правки» — не используй её, или используй только краткую версию плана (1–2 экрана) без расползания scope.

## Когда использовать

- По запросу пользователя: “спланируй”, “спроектируй”, “предложи варианты”, “составь план внедрения”.
- Когда задача/фикс **не до конца определены** и нужно сформировать Goal/Non-goals/Assumptions/Questions.
- Когда изменения **затрагивают архитектуру**, БД, публичные контракты, API или миграции.
- Перед крупным рефакторингом или внедрением нового паттерна/библиотеки.
- Когда лучше сделать серию маленьких PR/коммитов вместо “одного мегакоммита”.

## Принципы

- **Laravel‑way > самописные велосипеды** (FormRequest/Data-классы, Policies, Jobs, Events, Resources/Data-классы, Notifications, Validation rules, Eloquent scopes, etc.).
- **KISS/DRY**: сначала простая безопасная реализация, затем улучшения — только если они снижают сложность/риск.
- **Контракты важнее кода**: API, события, схемы БД, публичные методы — фиксируем и защищаем.
- **Безопасность и корректность** — приоритет №1.
- Если контекста не хватает — **делай явные допущения**, но не останавливайся: предложи план и список вопросов.

## Процесс планирования

### 1) Понять цель и ограничения (MUST)

Сформулируй:
- **Goal:** 1–2 предложения — что должно заработать/исправиться.
- **Non‑goals:** что НЕ делаем.
- **Constraints:** версия Laravel/PHP, окружение (Sail/Docker), БД, внешние интеграции, сроки, запреты (например «без миграций», «без изменения публичного API»).

Если данных мало — добавь блок:
- **Assumptions:** 3–7 пунктов с разумными предположениями.
- **Questions:** 3–7 уточнений (минимум, без «допроса»).

### 2) Быстро описать текущую картину (SHOULD)

Коротко:
- Какие сущности/модули участвуют.
- Где сейчас живёт логика (Controller/Service/Action/Model).
- Какие входы/выходы (HTTP/Jobs/Console/Events).

Если нет доступа к коду — сформулируй, **что нужно посмотреть** (файлы/таблицы/роуты), но всё равно продолжай с планом.

### 3) Предложить решения (MUST)

Дай минимум 2 варианта:
- **Recommended** (по умолчанию).
- **Alternative** (если ограничения/риски иные).

Для каждого:
- Плюсы/минусы.
- Риски.
- Что меняется в контрактах.

### 4) Декомпозиция на шаги (MUST)

Составь пошаговый план, ориентируясь на маленькие, проверяемые изменения.

Правила:
- Шаги должны быть **выполнимыми** и **проверяемыми**.
- Избегай «сделать магию» — каждый шаг должен объяснять *что* и *где*.
- Отдельно выделяй:
  - изменения схемы БД,
  - изменения публичного API,
  - миграции/сидеры,
  - фоновые процессы/очереди,
  - кеши,
  - правки конфигов.

### 5) Данные и миграции (если применимо)

- Нужно ли менять схему? (миграции)
- Нужна ли backfill‑миграция/команда для заполнения данных?
- Нужны ли индексы?
- Нужна ли транзакционность/блокировки?

### 6) Политики безопасности и доступ (если применимо)

- Авторизация (Policy/Gate/`authorize()` в FormRequest).
- Валидация (FormRequest/Rules).
- Массовое присваивание (`$fillable`/`$guarded`).
- Санитизация/экранирование (XSS), работа с файлами.

### 7) Тест‑план (SHOULD)

Опиши минимальный набор тестов:
- Feature: критические сценарии HTTP.
- Unit: бизнес‑логика/сервисы.
- DB: миграции/индексы/ограничения (где уместно).
- Регрессии: «что могло сломаться».

Важно:
- Не утверждай, что тесты были запущены, если нет реального вывода.

### 8) Rollout/rollback (если применимо)

- Нужен ли feature flag?
- Порядок деплоя (миграции до/после кода).
- Что мониторим (логи/метрики/ошибки).
- Как откатиться безопасно.

### 9) Definition of Done (MUST)

Список критериев готовности:
- Функциональность работает.
- Тесты добавлены/обновлены.
- Документация/README при необходимости.
- Нет деградации производительности/безопасности.

## Формат ответа (MUST)

Выдавай план **строго в таком порядке**:

1. **Goal / Non‑goals**
2. **Constraints**
3. **Assumptions** (если нужно)
4. **Questions** (если нужно)
5. **Recommended approach**
6. **Alternatives** (1–2)
7. **Step‑by‑step plan** (нумерованный, шаги небольшие)
8. **Data & migrations**
9. **Security & auth**
10. **Test plan**
11. **Rollout / rollback**
12. **Definition of Done**

## Если после плана просят «делай»

- Сначала предложи **первый минимальный шаг** (самый безопасный) и только потом переходи к следующему.
- Старайся делать изменения **атомарно** и сохранять читаемость diff.