tech-spec-composer - SKILL.md Agent Skill

name: tech-spec-composer description: "Сформировать техническое задание, готовое к исполнению Tier L: с явным контекстом, ограничениями, правилами стека, обязательными скиллами/инструментами, критериями приемки и артефактами передачи/ревью. Использовать при постановке задач для Cursor-агентов и Codex-исполнителей (API, боты, парсеры, публикация)."

Tech Spec Composer

Назначение

Скилл готовит короткое, однозначное ТЗ, которое можно исполнять без догадок: что менять, где менять, как проверять и какие доказательства приложить к ревью.

Принцип работы

Применять компактные guardrails из references/claude-imported-guards.md и references/root-task-tracker.md: не додумывать стратегические развилки, маркировать исполнителей, фиксировать preflight/smoke/concurrency/stage/API/SQL guards только когда они релевантны, а Root-задачу создавать самостоятельно при срабатывании tracker-триггера.

Порядок работы

Сформулировать цель и пользовательский результат в одном абзаце.
Зафиксировать контекст: репозиторий, затронутые модули, текущее поведение, внешние зависимости.
Проверить Root tracker trigger из references/root-task-tracker.md: если задача должна жить в портфельном трекере, создать или переиспользовать tsk-NNN до выдачи ТЗ и ссылаться на него в контексте.
Жёстко задать границы:

что входит;
что не входит;
какие зоны не трогать.

Для migration/operator/CLI-задач сначала собрать карту предметных зависимостей:

какие данные, классификаторы, состояния и правила нужны для реальной работы;
что уже есть в target system, а что ещё нужно перенести.

Выбрать один доменный режим из references/domain-modes.md и использовать только его checklist.
Если доступны product-review, eng-review, Product Review Snapshot или Engineering Review Snapshot, явно потребить их и перенести обязательные ограничения в ТЗ.
Составить детерминированные шаги реализации с привязкой к файлам/модулям и inline-маркерами Executor / Review; каждый Executor должен быть конкретным skill-исполнителем.
Если есть пользовательский поток, явно описать:

Контракт навигации;
Запрещённые элементы управления на happy-path.

Зафиксировать приёмку:

критерии;
команды проверки;
минимальные артефакты review-gate;
rollback и меры снижения риска.

Проверить, не допускает ли ТЗ дублирование общей инфраструктуры без явного архитектурного исключения.

Формат результата

Цель
Контекст
Границы задачи
Стек и ограничения
Consumed Review Artifacts
Обязательные скиллы/правила
Шаги реализации — с Executor на каждой существенной под-задаче и Review там, где есть security/contracts/migrations/concurrency/data-write риск
Контракт навигации
Запрещённые элементы управления
Preflight / Deployment Checklist (если применимо)
Concurrency & Idempotency (если применимо)
Stage Dependency Graph (если применимо)
Frontend Routes и API Endpoints отдельными таблицами (если применимо)
Критерии приёмки
Команды проверки
Артефакты review-gate
Переиспользование общей инфраструктуры
Артефакты передачи
Риски и откат

Правила качества

Основной язык: русский.
Требования должны быть исполнимыми без догадок и без расплывчатых формулировок.
Если сработал Root tracker trigger, ТЗ ссылается на созданную/найденную tsk-NNN, а не перекладывает создание задачи на оператора.
Не подменять предметную функциональность списком команд/экранов, если не закрыты доменные предпосылки.
Один основной документ по умолчанию; дополнительные матрицы и заметки допустимы только при реальной необходимости.
Для next/queue-потоков отсутствие forbidden controls должно быть проверяемым критерием приёмки.
Каждая существенная под-задача должна иметь конкретного skill-исполнителя, а рискованные пути — конкретный review skill; ТЗ без Executor, с неназначенным skill или с placeholder TBD/unassigned считается дефектным.
Для внешних write-path mock-only acceptance недостаточен; нужен gated live smoke criterion или явное обоснование невозможности.
Для SQL с window/gap/recursive логикой требуется 3-row mental trace в ТЗ.