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

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

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

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

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

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

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

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

Процесс

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

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

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

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

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

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

Шаблон — в references/spec-template.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 недели.
• 🚫 Никогда: не добавлять фичи «на всякий случай»; не выбирать технологию, которую невозможно запустить у пользователя; не начинать код без согласованного ТЗ (кроме тривиальных задач).

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

Выходные критерии (проверь перед передачей в 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+ агентских конфигов (шесть блоков ТЗ + трёхуровневые границы). Шаблон ТЗ — references/spec-template.md.