--- 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. **Что делает продукт** — 1-2 предложения простыми словами 2. **Кто пользователь** — кто будет это использовать и зачем 3. **Тип проекта** — если не ясно из контекста 4. **Что уже есть** — существующие материалы, наброски, прототипы, примеры 5. **Срок и команда** — кто делает и к какому дедлайну (опционально) 6. **Формат вывода** — markdown-файл, или просто текст в чате (по умолчанию: markdown-файл) Если пользователь уже дал достаточно информации — не задавай вопросы, сразу к шагу 2. --- ## Шаг 2 — Предложить структуру Покажи план ТЗ и спроси: «Генерировать? Или скорректировать?» ``` ПЛАН ТЗ — [название проекта] --- 1. Обзор проекта (что строим и зачем) 2. Цели и метрики успеха 3. Пользователи и сценарии использования 4. Функциональные требования 5. Архитектура / Функциональная схема 6. Технический стек и компоненты 7. Интеграции и зависимости 8. Нефункциональные требования 9. Этапы и сроки 10. Открытые вопросы --- Генерировать? Или добавить/убрать разделы? ``` Для аппаратных проектов добавляй: «Схема взаимодействия компонентов», «Производительность и экономика». Для AI/ML: «Данные и модели», «Метрики качества», «Инфраструктура инференса». Для веб: «Структура страниц», «Дизайн и UI», «SEO-требования». --- ## Шаг 3 — Генерация ТЗ ### Правила написания - **Конкретность**: «загрузка страницы < 2 сек» лучше чем «быстрая загрузка» - **Без канцелярита**: не «осуществляется реализация», а «система делает X» - **Измеримость**: каждое требование проверяемо — можно сказать «готово» или «не готово» - **Связность**: каждый раздел отвечает на вопрос команды, а не заполняет шаблон - **Таблицы для структуры**: компоненты, сравнения, требования — удобнее в таблице ### Универсальная структура ТЗ --- ```markdown # Техническое задание: [Название проекта] **Версия:** 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 | ... | ... | | БД | ... | ... | | Инфраструктура | ... | ... | --- ## 7. Интеграции и зависимости | Система | Тип интеграции | Что передаём/получаем | Приоритет | |---------|---------------|----------------------|-----------| | [API/сервис] | REST / Webhook / SDK | [данные] | MVP / Nice-to-have | --- ## 8. Нефункциональные требования ### 8.1 Производительность - [метрика]: [значение] ### 8.2 Надёжность - [uptime, retry-логика, fallback] ### 8.3 Безопасность - [авторизация, шифрование, доступы] ### 8.4 Масштабируемость - [ожидаемый рост нагрузки и как система с ним справится] --- ## 9. Этапы и сроки | Этап | Что входит | Результат (Deliverable) | Срок | |------|-----------|------------------------|------| | MVP | [минимальный набор функций] | [что сдаём] | [дата] | | v1.0 | ... | ... | ... | --- ## 10. Открытые вопросы | Вопрос | Кто отвечает | Срок ответа | |--------|-------------|-------------| | [неясность или риск] | [ответственный] | [когда нужен ответ] | --- ## Приложения (опционально) - Ссылки на прототипы / макеты - Схемы / диаграммы - Примеры аналогов ``` --- ### Адаптации по типу проекта **Аппаратный проект** — добавить после раздела 5: ```markdown ## 5.3 Физическая схема компонентов [описание зон: загрузка → обработка → сортировка → выход] ## Производительность и экономика - Производительность: [единиц в час] - Стоимость реализации: [оценка] - Окупаемость: [расчёт] ``` **AI/ML проект** — добавить: ```markdown ## Данные и модели - Источник данных: [откуда берём] - Объём датасета: [текущий / целевой] - Модель: [архитектура, фреймворк] - Метрики качества: Precision / Recall / F1 / latency - Инфраструктура инференса: [локально / API / edge] ``` **Веб/мобильное** — добавить: ```markdown ## Структура страниц [Карта сайта / экранов] ## Дизайн-требования - Фирменный стиль: [есть / нет / ссылка] - Брендбук: [ссылка или нет] - Устройства: desktop / mobile / tablet - Браузеры: Chrome, Safari, Firefox (последние 2 версии) ``` --- ## Шаг 4 — Сохранение Если пользователь хочет файл — сохранить в текущую директорию проекта: ```bash # Определить директорию 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». 1. Если файл не указан — спросить через AskUserQuestion 2. Прочитать файл (Read) 3. Применить изменение через Edit (не Write, чтобы не затирать) 4. Если изменение > 30% документа — сохранить v(N+1) 5. Подтвердить: «Раздел X обновлён. Файл: ./ТЗ_..._v2.md»