Навык OpenAI для создания плана

---
name: create-plan
description: Создай краткий план. Используй, когда пользователь явно просит план, связанный с задачей программирования.
metadata:
  short-description: Создать план
---

# Создание плана

## Цель

Преобразуй запрос пользователя в **единый, пригодный к выполнению план**, представленный в итоговом сообщении ассистента.

## Минимальный рабочий процесс

На протяжении всего процесса работай в режиме только чтения. Не записывай и не обновляй файлы.

1. **Быстро изучи контекст**
   - Прочитай `README.md` и очевидную документацию (`docs/`, `CONTRIBUTING.md`, `ARCHITECTURE.md`).
   - Просмотри связанные файлы (которые с наибольшей вероятностью будут затронуты).
   - Определи ограничения (язык, фреймворки, команды CI/тестирования, способ развёртывания).

2. **Задавай уточняющие вопросы только при блокирующей неопределённости**
   - Задай **не более 1–2 вопросов**.
   - Спрашивай только тогда, когда без ответа нельзя ответственно составить план; предпочтительны вопросы с вариантами ответа.
   - Если есть сомнения, но работа не заблокирована, сделай разумное допущение и продолжай.

3. **Создай план по шаблону ниже**
   - Начни с **1 короткого абзаца**, описывающего цель и подход.
   - Кратко и чётко обозначь, что **входит в объём работ**, а что **не входит**.
   - Затем предоставь **небольшой чек-лист** действий (по умолчанию 6–10 пунктов).
      - Каждый пункт должен быть конкретным действием и, где полезно, упоминать файлы/команды.
      - **Делай пункты атомарными и упорядоченными**: изучение → изменения → тесты → выпуск.
      - **Начинай с глагола**: «Добавить…», «Переработать…», «Проверить…», «Выпустить…».
   - Включи как минимум один пункт о **тестах/проверке** и один о **граничных случаях/рисках**, когда применимо.
   - При наличии неизвестных добавь небольшой раздел **Открытые вопросы** (не более 3).

4. **Не предваряй план метаобъяснениями; выведи только план по шаблону**

## Шаблон плана (соблюдай точно)

```markdown
# План

<1–3 sentences: what we’re doing, why, and the high-level approach.>

## Объём работ
- Входит:
- Не входит:

## Действия
[ ] <Step 1>
[ ] <Step 2>
[ ] <Step 3>
[ ] <Step 4>
[ ] <Step 5>
[ ] <Step 6>

## Открытые вопросы
- <Question 1>
- <Question 2>
- <Question 3>
```

## Рекомендации для пунктов чек-листа
Хорошие пункты:
- Указывают вероятные файлы/модули: src/..., app/..., services/...
- Называют конкретную проверку: «Запустить npm test», «Добавить модульные тесты для X»
- Включают безопасный выпуск, где уместно: флаг функции, план миграции, примечание об откате

Избегай:
- Расплывчатых шагов («разобраться с бэкендом», «сделать авторизацию»)
- Слишком большого числа микрошагов
- Написания фрагментов кода (план должен быть независим от конкретной реализации)