ТЗ и архитектура
@dev-spec
Превращает идею продукта в компактное ТЗ и план разработки для MVP — уточняет требования, выбирает минимальный стек, набрасывает архитектуру и разбивает работу на задачи. Применяйте для «хочу сделать приложение/сайт/бота/скрипт/программу», «напиши ТЗ», «спроектируй архитектуру», «с чего начать разработку», «помоги выбрать стек/язык», «оцени, сколько займёт». Не подходит для написания самого кода (dev-build), тестирования (dev-test), ведения проекта и памяти (dev-project) или тривиальной правки в одну строку.
Кому подходит навык ТЗ и архитектура
- Основателям и продуктовикам — превратить смутную идею в чёткое техзадание ещё до того, как писать код.
- Разработчикам-одиночкам и фрилансерам — зафиксировать требования, стек и критерий приёмки, чтобы не переделывать потом.
- Командам запуска MVP — разбить продукт на тонкие вертикальные срезы и понять, что в ядре, а что отложить.
- Тем, кто выбирает стек — получить осознанную рекомендацию под задачу и окружение, а не «модное».
Что можно сделать
- Собрать ТЗ для MVP — цель, ценность, критерий приёмки, стек с версиями, команды запуска, структура проекта, границы и модель данных. Шесть блоков, без воды.
- Выбрать минимальный стек — под тип задачи: веб-приложение, Telegram-бот, CLI, парсер, десктоп. С учётом того, что запустится у пользователя.
- Разбить работу на задачи — маленькие проверяемые куски, чтобы каждый можно было сделать и проверить изолированно.
- Оценить объём — понять, реально ли это MVP или потянет больше недели.
Связанные навыки: Разработка, Тестирование, Ведение проекта.
Как это работает: MVP — это не «всё, только меньше»
Главный принцип — однаключевая ценность: одна проблема пользователя → один путь её решения → всё остальное (соцсети, настройки профиля, тёмная тема, аналитика) выкидывается или откладывается. Сначала навык проводит короткое интервью, по одному вопросу за раз, чтобы не мучить вас. Затем собирается компактное ТЗ и сохраняется в SPEC.md — живой источник правды, к которому возвращаются следующие этапы.
Полезные детали
- Критерий приёмки записывается явно — потом его проверяет навык тестирования.
- Стек выбирается осознанно: то, что вы знаете, и то, что запустится у пользователя. На Windows Python может отсутствовать, но Node есть всегда.
- Границы трёхуровневые: ✅ всегда / ⚠️ спросить / 🚫 никогда — чтобы не добавлять фичи «на всякий случай».
- Согласование до кода: правки на этапе ТЗ стоят минуты, после кода — часы.
Готовы превратить идею в план? Запустите навык ТЗ и архитектура или начните с целого ИИ-разработчика.
Чем это ТЗ отличается от «большого» техзадания?
Оно компактное — шесть блоков вместо многостраничного документа: цель и ценность, стек с версиями, команды запуска, структура проекта, трёхуровневые границы и модель данных. Цель — поднять уверенность в требованиях до ~90%, а не написать диплом.
Нужно ли заранее знать стек и язык?
Нет. Навык задаёт короткое интервью (5–7 вопросов), уточняет платформу и окружение пользователя, а затем предлагает минимальный стек под тип задачи — веб-приложение, Telegram-бот, CLI, парсер или десктоп.
А если я не могу назвать одну главную задачу продукта?
Это нормально — именно такой вопрос навык задаст первым. Правило однойключевой ценности: одна проблема пользователя → один путь её решения → всё остальное выкидывается или откладывается. Без чёткого ядра ТЗ не собирается.
Подходит ли навык для мелкой правки в одну строку?
Нет. Для тривиальной правки или быстрого скрипта на 20 строк ТЗ избыточно. Этот навык включается, когда начинается новый проект или крупная фича — пока кода ещё нет или его немного.
Это платно?
Навыком можно пользоваться в рамках тарифа AgentHere — оплата идёт за токены при работе модели. Точные лимиты смотрите на странице тарифов.
ТЗ и архитектура для 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. Шесть блоков (не больше):
- Цель и ценность — одну 核心 задачу + критерий приёмки.
- Стек — конкретный и минимальный (с версиями). См. §3 ниже.
- Команды — как запускать, тестировать, собирать (реальные команды с флагами).
- Структура проекта — где код, тесты, данные.
- Границы — трёхуровневые: ✅ всегда / ⚠️ спросить / 🚫 никогда.
- Данные и модель — ключевые сущности и связи (текстом, без переусложнения).
Сохрани ТЗ в файл SPEC.md в корне проекта — это живой источник правды, к нему
возвращаются dev-build и dev-test.
3. Минимальный стек (выбрать осознанно)
Правило: выбирай то, что знаешь, и то, что запускается у пользователя. Не тянуть новую технологию ради любопытства. Конкретные рекомендации по типам задач:
| Тип задачи | Стек по умолчанию (MVP) |
|---|---|
| Веб-сайт / лендинг | HTML + CSS + минимум JS; или Next.js если нужна динамика |
| Веб-приложение | Next.js (React) + SQLite/Postgres; FastAPI если сложная логика |
| Telegram-бот | Python (aiogram) или Node (grammy) |
| CLI / скрипт | Python или Node — что уже стоит у пользователя |
| Парсер / автоматизация | Python (requests/BeautifulSoup) или Node |
| Десктоп | Electron (если веб-стек) — но это тяжело для MVP, сначала CLI/веб |
Ключевой вопрос про окружение: на 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 недели.
- 🚫 Никогда: не добавлять фичи «на всякий случай»; не выбирать технологию, которую невозможно запустить у пользователя; не начинать код без согласованного ТЗ (кроме тривиальных задач).
Отговорки и почему они не работают
| Отговорка | Почему мимо |
|---|---|
| «Напишу ТЗ потом, сразу в код» | Без ТЗ код расползается; правки после кода в 10× дороже. Минимум 15 строк — и вперёд. |
| «Добавлю регистрацию/настройки сразу» | Это не MVP. Сначала核心ную ценность, остальное — после того, как ядро заработает. |
| «Стек выберу по ходу» | Смена стека в середине = снос всего. Один абзац про стек в ТЗ — и вопрос закрыт. |
| «Критерий приёмки и так понятен» | Если не записан — dev-test не сможет проверить. Запиши явно. |
Выходные критерии (проверь перед передачей в 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.