interview

name	interview
description	Структурированный сбор требований через серию вопросов. Используй, когда задача описана устно/неформально (не из тикета трекера) и перед началом работы нужно прояснить scope, AC и edge cases.
allowed-tools	["AskUserQuestion","Write"]

Interview: сбор требований через вопросы

Помоги пользователю структурировать неформальное описание задачи в полные требования, готовые к передаче в скиллы test-cases или testing.

Когда применять

• Задача описана устно или общими словами, без тикета
• Нет AC, нет макетов, нет чёткого scope
• Пользователь сам не уверен, что именно тестировать/автоматизировать

Если задача уже из трекера (Jira и т.п.) с полным описанием — этот скилл не нужен: собери контекст прямо из тикета (через MCP трекера: описание, комментарии, вложения, связанные задачи) и передай в test-cases.

Процесс

Раунд 1: scope и контекст. Задай 3-4 вопроса через AskUserQuestion:

• Что именно проверяем (фича, страница, элемент)
• Где это живёт (URL, экран, путь в навигации)
• Тип задачи (новая функциональность / регресс / баг)
• Платформы (desktop / mobile / оба)

Раунд 2: поведение и AC. На основе ответов 1-го раунда:

• Happy path — какое поведение считается корректным
• Edge cases — что важно проверить из негативных сценариев
• Состояния UI (loading, error, empty, disabled) — если применимо
• Интеграции — есть ли API / внешние сервисы

Раунд 3: уточнения по оставшимся пробелам. Только если после 1-2 раундов остались критичные пробелы. Группируй связанные вопросы.

Максимум 3 раунда. Если требования всё ещё неполные — зафиксируй пробелы как «Вопросы для аналитика/PM» и работай с тем, что есть.

Формат вывода

После завершения опроса собери структурированный summary:

# Требования: <короткое название задачи>

## Контекст
- Тип: <новая фича / регресс / баг>
- Платформы: <desktop / mobile / оба>
- URL / расположение: <…>

## Scope
<что именно проверяем, кратко>

## Acceptance Criteria
- <AC 1>
- <AC 2>

## Сценарии
**Happy path:** <описание>

**Edge cases:**
- <case 1>
- <case 2>

## Интеграции
<API, внешние сервисы — если есть>

## Открытые вопросы для аналитика/PM
- <вопрос 1>

Сохрани summary в md-файл (например, requirements_<task_name>.md в текущей рабочей директории) и предложи пользователю передать его в test-cases или testing.

Что предпочитать

• Лучше 4 точных вопроса, чем 10 шаблонных
• Привязывай вопросы к ответам предыдущего раунда, а не задавай по чек-листу
• Если пользователь отвечает «не знаю» — фиксируй как вопрос для аналитика, не дави
• В вопросах используй конкретные варианты ответа (опции AskUserQuestion), а не открытые формулировки