Interview

Skill akovalion/paranoid-qa/ru/skills/interview

Claude Code skills that turn an AI agent into a meticulous QA engineer. Evidence or it didn't happen.

Install

npx -y skills add akovalion/paranoid-qa --skill interview

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Структурированный сбор требований через серию вопросов. Используй, когда задача описана устно/неформально (не из тикета трекера) и перед началом работы нужно прояснить scope, AC и edge cases.

SKILL.md

4.3 KB, as published. Nobody here has run it

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), а не открытые формулировки