interview git:20260708.dbb71c9A

Immutable. This exact content never changes and is served at /api/v1/blob/52f33ee14b1443be.

---
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:

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

## Контекст
- Тип: <новая фича / регресс / баг>
- Платформы: <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), а не открытые формулировки