메뉴
Structured requirements gathering through a series of questions. Use when the task is described verbally/informally (not from an issue tracker ticket) and scope, AC, and edge cases need clarifying before work starts.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Составление тест-кейсов по best practice QA с экспортом в CSV для импорта в Zephyr Scale (Option 1) или созданием напрямую через MCP вашей TMS. Используй, когда пользователь просит сгенерировать, составить или подготовить тест-кейсы, чек-листы или CSV для импорта в TMS.
Test case authoring per QA best practices, with CSV export for Zephyr Scale import (Option 1) or direct creation via your TMS MCP. Use when the user asks to generate, write, or prepare test cases, checklists, or CSV for TMS import.
Универсальный фреймворк тестирования (frontend + backend) — дотошный прогон любой задачи на тестирование с доказательной дисциплиной. Используй, когда нужно протестировать фичу/форму/билд/API/сервис, составить план тестирования, прогнать проверки, провести исследовательское или регрессионное тестирование, найти дефекты.
Universal testing framework (frontend + backend) — a meticulous run of any testing task with evidence discipline. Use when you need to test a feature/form/build/API/service, draft a test plan, run checks, perform exploratory or regression testing, or find defects.
Ревью только что написанных или изменённых автотестов на соответствие best practices TypeScript + Playwright (по официальной документации) и конвенциям вашего проекта. Используй по /test-review либо после написания/правки любого теста (UI E2E, API, UI+API, моки, visual, mobile) или Page Object/фикстуры/констант — до коммита. Выдаёт приоритизированный список замечаний с severity, привязкой к строкам и готовыми фиксами.
Review of just-written or modified autotests against TypeScript + Playwright best practices (per official documentation) and your project's conventions. Use via /test-review or after writing/editing any test (UI E2E, API, UI+API, mocks, visual, mobile) or a Page Object/fixture/constants — before commit. Produces a prioritized list of findings with severity, line references, and ready-made fixes.
| name | interview |
| description | Structured requirements gathering through a series of questions. Use when the task is described verbally/informally (not from an issue tracker ticket) and scope, AC, and edge cases need clarifying before work starts. |
| allowed-tools | — AskUserQuestion — Write |
Help the user turn an informal task description into complete requirements ready to hand off to the test-cases or testing skills.
If the task already comes from an issue tracker (Jira etc.) with a full description — this skill is not needed: gather context straight from the ticket (via the tracker's MCP: description, comments, attachments, linked issues) and hand off to test-cases.
Round 1: scope and context. Ask 3-4 questions via AskUserQuestion:
Round 2: behavior and AC. Based on the round 1 answers:
Round 3: clarifications on remaining gaps. Only if critical gaps remain after rounds 1-2. Group related questions.
Maximum 3 rounds. If the requirements are still incomplete — log the gaps as "Questions for the analyst/PM" and work with what you have.
Once the interview is done, assemble a structured summary:
# Requirements: <short task name>
## Context
- Type: <new feature / regression / bug>
- Platforms: <desktop / mobile / both>
- URL / location: <…>
## Scope
<what exactly is being checked, briefly>
## Acceptance Criteria
- <AC 1>
- <AC 2>
## Scenarios
**Happy path:** <description>
**Edge cases:**
- <case 1>
- <case 2>
## Integrations
<APIs, external services — if any>
## Open questions for the analyst/PM
- <question 1>
Save the summary to an md file (e.g. requirements_<task_name>.md in the current working directory) and offer to hand it off to test-cases or testing.