| name | tz |
| description | Составляет чёткое и практичное Техническое Задание (ТЗ) для технических проектов: аппаратные стенды, веб-приложения, мобильные приложения, AI/ML-системы, автоматизация, интеграции, внутренние инструменты. Не ГОСТ-бюрократия, а живой документ для команды. Вызывай когда пользователь говорит: «составь ТЗ», «напиши техническое задание», «оформи требования», «сделай ТЗ на проект», «помоги с ТЗ», «/тз».
|
| allowedTools | ["Read","Write","Edit","Bash","Glob","Grep","WebSearch","WebFetch","AskUserQuestion","TodoWrite"] |
Скилл: Техническое Задание (ТЗ)
Философия
Хорошее ТЗ — не бюрократический документ по ГОСТ, а живое описание продукта.
Оно отвечает на три вопроса: что строим, как это работает, как поймём, что готово.
Структура адаптируется под тип проекта, не под шаблон ради шаблона.
Шаг 1 — Сбор контекста
Сначала определи тип проекта по сообщению пользователя:
| Тип | Признаки |
|---|
| Аппаратный | стенд, железо, датчики, конвейер, механика, Arduino, Raspberry Pi |
| Веб-приложение | сайт, платформа, SaaS, CRM, дашборд, API, бэкенд |
| Мобильное приложение | iOS, Android, Flutter, React Native |
| AI/ML-система | нейросеть, распознавание, классификация, LLM, автоматизация с AI |
| Интеграция/автоматизация | связать системы, парсер, бот, скрипт, ETL, воркфлоу |
| Внутренний инструмент | админка, внутренний сервис, автоматизация процессов компании |
Если тип неочевиден — уточни через AskUserQuestion.
Уточняющие вопросы (одним блоком через AskUserQuestion)
Задай всё сразу:
- Что делает продукт — 1-2 предложения простыми словами
- Кто пользователь — кто будет это использовать и зачем
- Тип проекта — если не ясно из контекста
- Что уже есть — существующие материалы, наброски, прототипы, примеры
- Срок и команда — кто делает и к какому дедлайну (опционально)
- Формат вывода — markdown-файл, или просто текст в чате (по умолчанию: markdown-файл)
Если пользователь уже дал достаточно информации — не задавай вопросы, сразу к шагу 2.
Шаг 2 — Предложить структуру
Покажи план ТЗ и спроси: «Генерировать? Или скорректировать?»
ПЛАН ТЗ — [название проекта]
---
1. Обзор проекта (что строим и зачем)
2. Цели и метрики успеха
3. Пользователи и сценарии использования
4. Функциональные требования
5. Архитектура / Функциональная схема
6. Технический стек и компоненты
7. Интеграции и зависимости
8. Нефункциональные требования
9. Этапы и сроки
10. Открытые вопросы
---
Генерировать? Или добавить/убрать разделы?
Для аппаратных проектов добавляй: «Схема взаимодействия компонентов», «Производительность и экономика».
Для AI/ML: «Данные и модели», «Метрики качества», «Инфраструктура инференса».
Для веб: «Структура страниц», «Дизайн и UI», «SEO-требования».
Шаг 3 — Генерация ТЗ
Правила написания
- Конкретность: «загрузка страницы < 2 сек» лучше чем «быстрая загрузка»
- Без канцелярита: не «осуществляется реализация», а «система делает X»
- Измеримость: каждое требование проверяемо — можно сказать «готово» или «не готово»
- Связность: каждый раздел отвечает на вопрос команды, а не заполняет шаблон
- Таблицы для структуры: компоненты, сравнения, требования — удобнее в таблице
Универсальная структура ТЗ
# Техническое задание: [Название проекта]
**Версия:** 1.0
**Дата:** YYYY-MM-DD
**Автор:** [имя]
**Статус:** Черновик / На согласовании / Утверждено
---
## 1. Обзор проекта
### 1.1 Что строим
[1-3 предложения: суть продукта простыми словами]
### 1.2 Зачем это нужно
[Проблема, которую решаем. Почему сейчас. Что будет, если не делать.]
### 1.3 Результат
[Что должно существовать на выходе — конкретно: стенд, приложение, API, скрипт]
---
## 2. Цели и метрики успеха
| Цель | Метрика | Целевое значение |
|------|---------|-----------------|
| [цель 1] | [как измеряем] | [число/факт] |
| [цель 2] | ... | ... |
---
## 3. Пользователи и сценарии
### 3.1 Кто использует
| Роль | Описание | Основные задачи |
|------|----------|-----------------|
| [роль 1] | [кто это] | [что делает в системе] |
### 3.2 Ключевые сценарии (User Stories)
- **Как [роль]** я хочу [действие], чтобы [цель]
- ...
---
## 4. Функциональные требования
### 4.1 [Модуль / Функция 1]
**Описание:** [что делает]
**Требования:**
- [ ] [конкретное требование — проверяемое]
- [ ] ...
**Ограничения:** [чего не делает, что за рамками]
### 4.2 [Модуль / Функция 2]
...
---
## 5. Архитектура / Функциональная схема
[Словесное описание компонентов и их взаимодействия]
### 5.1 Компоненты системы
| Компонент | Роль | Технология |
|-----------|------|-----------|
| [компонент] | [что делает] | [чем реализован] |
### 5.2 Схема взаимодействия
[Описание потока данных / управляющих сигналов: шаг за шагом]
1. Пользователь делает X
2. Система Y обрабатывает Z
3. Результат передаётся в...
---
## 6. Технический стек
| Слой | Технология | Обоснование выбора |
|------|-----------|-------------------|
| Frontend | ... | ... |
| Backend | ... | ... |
| БД | ... | ... |
| Инфраструктура | ... | ... |
---
| Система | Тип интеграции | Что передаём/получаем | Приоритет |
|---------|---------------|----------------------|-----------|
| [API/сервис] | REST / Webhook / SDK | [данные] | MVP / Nice-to-have |
---
[метрика]: [значение]
[uptime, retry-логика, fallback]
[авторизация, шифрование, доступы]
[ожидаемый рост нагрузки и как система с ним справится]
---
| Этап | Что входит | Результат (Deliverable) | Срок |
|------|-----------|------------------------|------|
| MVP | [минимальный набор функций] | [что сдаём] | [дата] |
| v1.0 | ... | ... | ... |
---
| Вопрос | Кто отвечает | Срок ответа |
|--------|-------------|-------------|
| [неясность или риск] | [ответственный] | [когда нужен ответ] |
---
Ссылки на прототипы / макеты
Схемы / диаграммы
Примеры аналогов
Адаптации по типу проекта
Аппаратный проект — добавить после раздела 5:
## 5.3 Физическая схема компонентов
[описание зон: загрузка → обработка → сортировка → выход]
## Производительность и экономика
- Производительность: [единиц в час]
- Стоимость реализации: [оценка]
- Окупаемость: [расчёт]
AI/ML проект — добавить:
## Данные и модели
- Источник данных: [откуда берём]
- Объём датасета: [текущий / целевой]
- Модель: [архитектура, фреймворк]
- Метрики качества: Precision / Recall / F1 / latency
- Инфраструктура инференса: [локально / API / edge]
Веб/мобильное — добавить:
## Структура страниц
[Карта сайта / экранов]
## Дизайн-требования
- Фирменный стиль: [есть / нет / ссылка]
- Брендбук: [ссылка или нет]
- Устройства: desktop / mobile / tablet
- Браузеры: Chrome, Safari, Firefox (последние 2 версии)
Шаг 4 — Сохранение
Если пользователь хочет файл — сохранить в текущую директорию проекта:
pwd
Сохранить через Write tool: ./ТЗ_[slug-проекта]_v1.md
Формат slug: ТЗ_lego-sorter_v1.md, ТЗ_web-platform_v1.md
Шаг 5 — Итог
После генерации вывести:
ТЗ ГОТОВО
---
Файл: ./ТЗ_[название]_v1.md
Разделы: [N]
---
Следующие шаги:
• Добавь реальные сроки и ответственных в раздел 9
• Заполни открытые вопросы в разделе 10
• Согласуй с командой / заказчиком
• При изменениях — сохрани как v2: ./ТЗ_[название]_v2.md
РЕЖИМ 2: Доработка существующего ТЗ
Триггеры: «дополни ТЗ», «добавь раздел», «обнови требования», «переработай раздел X».
- Если файл не указан — спросить через AskUserQuestion
- Прочитать файл (Read)
- Применить изменение через Edit (не Write, чтобы не затирать)
- Если изменение > 30% документа — сохранить v(N+1)
- Подтвердить: «Раздел X обновлён. Файл: ./ТЗ_..._v2.md»
