---
name: vision-builder-ru
description: |
  Скилл для формирования чёткой визии проекта и генерации всей базовой документации.
  ОБЯЗАТЕЛЬНЫЕ ТРИГГЕРЫ: "сформируй визию", "создай визию", "визия проекта", "формируем проект",
  "нужна визия", "начнём с визии", "определи проект", "что мы строим", "план проекта",
  "с чего начнём", "хочу построить X", "опиши проект", "структура проекта".
  Использовать когда: пользователь описывает идею и хочет её структурировать,
  нужно пройти путь идея → стек → фазы, нет чёткого понимания А и Б.
  НЕ использовать: если проект уже в работе и визия зафиксирована без изменений.
metadata:
  author: N.V
  version: "1.0"
  lang: ru
user-invocable: true
---

## Цель

Превратить идею (или существующий контекст) в зафиксированную визию проекта и набор
живых рабочих документов. Визия — это якорь. Все остальные файлы производятся от неё
и должны оставаться с ней согласованными на протяжении всего проекта.

## Выходные файлы

| Файл | Роль | Стабильность |
|------|------|--------------|
| `VISION.md` | Что, почему, А→Б, конечный результат. Читая — понимаешь проект. | Стабильный после утверждения |
| `REQUIREMENTS.md` | Технические и нетехнические требования | Стабильный, мелкие правки допустимы |
| `PHASES.md` | Фазы выполнения + подзадачи, которые вылезают в процессе | Живой документ |
| `WORKFLOW.md` | Инструменты, агенты, MCPs, сервисы проекта | Обновляется при изменении стека |

---

## Шаг 1 — Сначала читаем контекст

Прежде чем задавать вопросы — проверить что уже есть:

1. Прочитать `VISION.md` если существует
2. Проанализировать текущий диалог: какие цели, идеи, решения уже описаны
3. Проверить `REQUIREMENTS.md`, `PHASES.md`, `WORKFLOW.md` если есть

Сформировать внутреннее понимание:
- Что хочет построить пользователь?
- Что есть сейчас (точка А)?
- Что должно быть в конце (точка Б)?
- Что известно о стеке?
- Где пробелы?

Спрашивать только о пробелах. Не переспрашивать то, что уже ясно из контекста.

---

## Шаг 2 — Уточняющие вопросы (один за раз)

Спрашивать только то, что неизвестно. Всегда один вопрос на сообщение.

Ключевые вопросы если не выяснены из контекста:

1. **Точка А:** Что есть сейчас? (код, ручной процесс, ничего?)
2. **Точка Б:** Как выглядит успех? (конкретно и наблюдаемо)
3. **Почему:** Какую проблему решает и почему текущая ситуация не устраивает?
4. **Формат результата:** Что получает пользователь/система на выходе? (файл, API, сервис, etc.)
5. **Стек:** Какие технологии предпочтительны или уже решены?
6. **Ограничения:** Сроки, команда, технические лимиты — всё что влияет на решения?

Если пользователь уже ответил на это в диалоге — подтвердить понимание вместо вопроса:
> "Понимаю цель как X — правильно?"

---

## Шаг 3 — Стек + актуальные версии

Когда стек определён:

1. Использовать **context7** для получения текущих стабильных версий каждой зависимости
   - `resolve-library-id` → `query-docs` для версии и ключевых API
   - На этом этапе только версии, не полная документация
2. Добавить версии в WORKFLOW.md

context7 используется по прямому назначению: найти текущие версии и авторитетные доки.
Не усложнять — только версии.

---

## Шаг 4 — Генерация документов

Генерировать файлы по порядку. После каждого — подтверждение пользователя перед следующим.

### VISION.md

```markdown
# [Название проекта] — Визия

## Что мы строим
[Один абзац. Чётко, без жаргона. Незнакомый с проектом человек должен понять.]

## Точка А — Текущее состояние
[Что есть сейчас. В чём боль. Почему нужен этот проект.]

## Точка Б — Конечное состояние
[Что будет после завершения проекта. Конкретно и наблюдаемо.]

## Почему
[Проблема которую решаем. Почему текущая ситуация неприемлема.]

## Конечный результат
[Что получает пользователь/система. Формат, интерфейс, deliverable.]

## MVP
[Минимальная версия которая доказывает что идея работает. Явно указать что вырезано.]

## Готово когда
[Конкретное, проверяемое условие. "Могу запустить X и получить Y." Не "это работает."]

## Стек
[Технологии + версии. Только подтверждённое.]
```

**Этот файл — якорь.** После утверждения он не меняется, если не меняется фундаментальное
направление проекта. Завершение фаз и мелкие правки VISION.md не затрагивают.

---

### REQUIREMENTS.md

```markdown
# [Название проекта] — Требования

## Функциональные требования
- [Что система должна делать]

## Нефункциональные требования
- [Производительность, надёжность, безопасность, масштабируемость]

## Ограничения
- [Технические, временные, ресурсные лимиты]

## Вне скоупа
- [Явно что проект НЕ делает — предотвращает расползание скоупа]
```

---

### PHASES.md

```markdown
# [Название проекта] — Фазы

> Живой документ. Фазы стабильны. Подзадачи появляются в процессе и добавляются сюда.
> Все подзадачи из Фазы N закрыть до начала Фазы N+1.

## Фаза 1 — [Название]
**Цель:** [Что достигает эта фаза]
**Готово когда:** [Проверяемое условие]

### Задачи
- [ ] [задача]

### Подзадачи из фазы
_(Добавляются в процессе. Приоритизировать и закрыть до Фазы 2.)_

---

## Фаза 2 — [Название]
...
```

**Правила для PHASES.md:**
- Фазы можно обновить при значительных изменениях — но только если это согласуется с VISION.md
- Подзадачи которые вылезли — в секцию "Подзадачи из фазы" текущей фазы
- Если подзадачи меняют скоуп настолько что нужно менять VISION.md — стоп, переосмысляем
- К Фазе 5 проект не должен выглядеть принципиально иначе чем в Фазе 1

---

### WORKFLOW.md

```markdown
# [Название проекта] — Инструменты и Workflow

## Стек
| Технология | Версия | Назначение |
|------------|--------|------------|

## Агенты / MCPs
| Инструмент | Назначение |
|------------|------------|

## Внешние сервисы
| Сервис | Назначение |
|--------|------------|

## Поток данных
[Кратко как данные движутся через систему]
```

---

## Шаг 5 — Подтверждение и фиксация

После генерации всех четырёх файлов:

1. Краткое резюме пользователю:
   > "Вот что мы определили: [2-3 предложения]. VISION.md теперь якорь проекта.
   > PHASES.md — живой документ, обновляй его когда вылезают подзадачи, но держи согласованным с визией."

2. Спросить: "Всё верно? Что-то менять до фиксации визии?"

3. Если нужны правки — обновить только конкретный файл. Не перегенерировать всё.

4. После утверждения — визия зафиксирована. Следующие сессии начинают с чтения VISION.md.

---

## Критические правила

- **Контекст первым** — не спрашивать то, что уже известно из диалога или файлов
- **Один вопрос за раз** — пачка вопросов даёт поверхностные ответы
- **VISION.md — якорь** — фазы и требования служат ему, а не наоборот
- **"Готово когда" должно быть проверяемым** — "это работает" не считается
- **context7 только для версий на этом этапе** — полные доки нужны при разработке
- **Не усложнять PHASES.md** — фазы стабильны, подзадачи — гибкая часть
- **Секция "Вне скоупа" обязательна** — предотвращает дрейф проекта