Turns a product idea into a compact spec and a build plan for an MVP: interviews for requirements, picks a minimal stack, sketches the architecture, saves SPEC.md, breaks the work into verifiable tasks. Use when the user says «хочу сделать приложение/сайт/бота/скрипт», «напиши ТЗ», «спроектируй архитектуру», «с чего начать разработку», «помоги выбрать стек/язык», «оцени, сколько займёт». Do NOT use for writing the actual code (dev-build), testing (dev-test), deployment (dev-deploy), project tracking (dev-project), or a one-line trivial edit.

ТЗ и архитектура для MVP

Превратить смутную идею в чёткое техническое задание и план — до того, как писать код. Цель: чтобы разработка шла по рельсам, а не по наитию. MVP — это не «урезанный продукт», а минимальная версия, которая уже решает задачу пользователя.

Когда активирован этот навык

• Пользователь говорит «хочу сделать / создать / разработать» приложение, сайт, бота, скрипт, интеграцию, парсер.
• Просит ТЗ, архитектуру, план, оценить сроки, выбрать стек.
• Начинает новый проект или крупную фичу — пока кода ещё нет (или его мало).

Не активируй, если задача — мелкая правка, быстрый скрипт в 20 строк или ответ на вопрос. Там ТЗ избыточно. И не путай с написанием кода (dev-build) или тестами (dev-test).

Главный принцип: MVP — это не «всё, только меньше»

MVP отвечает на вопрос «какое ядро уже приносит пользу?», а не «что успеем за неделю?». Правило одной ключевой ценности: одна проблема пользователя → один путь её решения → всё остальное (регистрация через соцсети, настройки профиля, тёмная тема, аналитика, админка) выкидывается или откладывается. Если пользователь не может назвать одну главную задачу продукта — это первый вопрос, который задаёшь ты.

Процесс

1. Интервью (5–7 вопросов, не больше)

Задавай по одному вопросу за раз, блоком, чтобы не мучить пользователя. Цель — поднять уверенность в требованиях до ~90%, а не написать диплом.

Обязательные вопросы:

• Что главное? Какую одну задачу решаем? Кто пользователь и когда ему больно?
• Как выглядит успех? Что пользователь сможет сделать, чтобы сказать «оно работает»? Это и есть критерий приёмки — его потом проверяет dev-test.
• Платформа и окружение: веб / десктоп / Telegram-бот / CLI / мобильное? Какая ОС у пользователя (для запуска)? Это влияет на выбор стека.
• Данные: что хранить, откуда брать, сколько примерно? Нужна ли авторизация?
• Ограничения: бюджет, сроки, «нельзя платить иностранцам», должен работать без интернета, есть ли готовые API/ключи.

Если пользователь отвечает «не знаю» — предложи 2–3 варианта по умолчанию и объясни компромисс. Не уходи в рассуждения на 20 экранов.

2. Техническое задание (компактное)

Шаблон — в конце этого навыка (§Шаблон SPEC.md). Шесть блоков (не больше):

1. Цель и ценность — одну ключевую задачу + критерий приёмки.
2. Стек — конкретный и минимальный (с версиями). См. §3 ниже.
3. Команды — как запускать, тестировать, собирать (реальные команды с флагами).
4. Структура проекта — где код, тесты, данные.
5. Границы — трёхуровневые: ✅ всегда / ⚠️ спросить / 🚫 никогда.
6. Данные и модель — ключевые сущности и связи (текстом, без переусложнения).

Сохрани ТЗ в файл SPEC.md в корне проекта — это живой источник правды, к нему возвращаются dev-build и dev-test.

3. Минимальный стек (выбрать осознанно)

Правило: выбирай то, что знаешь, и то, что запускается у пользователя. Не тянуть новую технологию ради любопытства. Конкретные рекомендации по типам задач:

Ключевой вопрос про окружение: на Windows у пользователя может не быть Python и Unix-утилит, но Node есть всегда (вшит в десктоп AgentHere). Если не уверен, что у пользователя стоит Python — предложи Node, или спроси. Подробности про кросс-платформу — в навыке dev-build.

4. Разбивка на задачи

Раздели ТЗ на маленькие, проверяемые куски — каждый можно сделать и проверить изолированно. Плохо: «сделать авторизацию». Хорошо: «создать форму регистрации с проверкой email → сохранить пользователя в SQLite → проверять уникальность email».

Задачи записывай чек-листом — его потом ведёт навык dev-project (todowrite + журнал). Порядок: сначала путь пользователя от начала до конца тонким срезом (vertical slice), а уже потом — толщина (валидация, ошибки, красота).

5. Согласование

Покажи пользователю ТЗ + стек + первые 3–5 задач и получи «ок» до кода. Это ключевая точка: правки на этапе ТЗ стоят минуты, правки после кода — часы. Если пользователь торопит («да просто напиши уже») — сделай ультракомпактное ТЗ (цель + стек

• критерий приёмки, 15 строк), но согласуй его.

Границы (трёхуровневые, как в ТЗ)

• ✅ Всегда: записать критерий приёмки; выбрать минимальный стек; сохранить SPEC.md.
• ⚠️ Спросить: если пользователь не назвал платформу/ОС; если предлагаешь нестандартный стек; если MVP-объём реально потянет > 1 недели.
• 🚫 Никогда: не добавлять фичи «на всякий случай»; не выбирать технологию, которую невозможно запустить у пользователя; не начинать код без согласованного ТЗ (кроме тривиальных задач).

Существующий проект (не с нуля)

Если пользователь приходит с уже существующим проектом («вот моя папка, добавь X / почини Y») — не строй полный MVP-ТЗ заново:

1. Сначала прочитай контекст проекта: README.md, AGENTS.md (если есть), package.json/pyproject.toml, структуру папок. Пойми, как запускается, как тестируется, какой стиль.
2. Напиши короткое ТЗ на изменение (5–10 строк): что меняем, зачем, критерий «стало работать» (как проверить), что не трогаем (рабочие места, которые можно сломать). Сохрани как SPEC.md (или допиши раздел в существующий).
3. Согласуй короткое ТЗ с пользователем — как и полное.

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

Отговорки и почему они не работают

Выходные критерии (проверь перед передачей в dev-build)

• Названа одна главная задача пользователя.
• Записан критерий приёмки — как поймём, что «работает».
• Выбран минимальный стек, совместимый с окружением пользователя.
• SPEC.md сохранён в корне проекта (или отдан пользователю).
• Задачи разбиты на проверяемые куски; первые 3–5 согласованы с пользователем.

Источники подхода: spec-driven development (GitHub Spec Kit), Addy Osmani «How to write a good spec for AI agents» (2026), анализ 2500+ агентских конфигов (шесть блоков ТЗ + трёхуровневые границы).

Шаблон SPEC.md

Копируй в SPEC.md в корне проекта и заполняй. Это живой документ: обновляй, когда меняются решения или выкидываются фичи; dev-build и dev-test возвращаются к нему как к источнику правды.

# SPEC.md — <название проекта>

## 1. Цель и ценность
- Одна главная задача: <что пользователь делает продуктом; одна фраза>
- Кто пользователь: <роль/контекст>
- Критерий приёмки: <конкретное действие + ожидаемый результат, проверяемое>.
  Пример: «пользователь вставляет ссылку на товар WB → получает историю цены за 30
  дней графиком → может скачать CSV». Это проверяет dev-test.
- Что НЕ входит в MVP (явно): <регистрация, профили, оплата, админка, мультиязычность…>

## 2. Стек (конкретный, минимальный)
- Язык/фреймворк: <название + версия, напр. Python 3.12 + FastAPI 0.115>
- База данных / хранилище: <SQLite / JSON-файл / Postgres — простейшее>
- Фронтенд (если есть): <HTML/CSS / Next.js>
- Зависимости: <только необходимые, по одной на задачу>
- Окружение запуска: <ОС пользователя, что уже стоит — критично для Windows>

## 3. Команды (реальные, с флагами)
- Установить зависимости: <команда>
- Запустить: <команда>
- Запустить тесты: <команда>
- Собрать/упаковать (если надо): <команда>

## 4. Структура проекта
<корень>/
  src/          — код
  tests/        — тесты
  data/         — данные/БД
  SPEC.md       — этот файл

## 5. Границы (✅ / ⚠️ / 🚫)
- ✅ Всегда: <напр. запускать тесты перед завершением задачи; следовать стилю кода>
- ⚠️ Спросить: <напр. менять схему БД; добавлять зависимость; трогать конфиг>
- 🚫 Никогда: <напр. коммитить секреты; править node_modules/.venv; удалять падающий тест>

## 6. Данные и модель (ключевые сущности)
- <Сущность A>: <поля, связи>. Пример: `User { id, email, created_at }`.
- Внешние источники: <API/файлы, откуда берём данные, нужен ли ключ>

## Чек-лист задач (MVP, тонким срезом)
1. <первый сквозной путь от старта до результата — самый тонкий>
2. <толщина: валидация, ошибки>
3. <толщина: удобство, полировка>

## Журнал решений (заполняется по ходу)
- <дата> — Решили <X> вместо <Y>, потому что <причина>. (см. также DEV-JOURNAL.md)