vision-builder-ru

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

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

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

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

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

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

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

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

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

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

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

---

REQUIREMENTS.md

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

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

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

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

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

---

PHASES.md

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

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

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

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

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

---

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

Правила для PHASES.md:

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

---

WORKFLOW.md

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

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

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

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

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

---

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

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

1. Краткое резюме пользователю:

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

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

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

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

---

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

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