Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/akovalion/paranoid-qa/interviewnpx skills add akovalion/paranoid-qa --skill interviewgit clone --depth 1 https://github.com/akovalion/paranoid-qaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/akovalion/paranoid-qa/interview)<a href="https://agentmods.dev/skills/akovalion/paranoid-qa/interview"><img src="https://agentmods.dev/badge/skills/akovalion/paranoid-qa/interview.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00052 | $0.00791 |
| Opus 5 | $0.00026 | $0.00396 |
| Sonnet 5 | $0.00010 | $0.00158 |
| Haiku 4.5 | $0.00005 | $0.00079 |
Grade A, and why
interview scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 78 lines · 52 tokens per session scan A 52f33ee14b14
interview is a skill published in the GitHub repository akovalion/paranoid-qa (13 stars, last pushed 3d ago), licensed MIT. It adds 52 tokens to every session and 791 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
mk:qa
Systematically QA test a web application and fix bugs found. Runs QA testing, then iteratively fixes bugs in source code, committing each fix atomically and re-verifying. Use when asked to "qa", "QA", "test this site", "find bugs", "test and fix", or "fix what's broken". Proactively suggest when the user says a…
automated-e2e-testing
将手动测试用例转为 Playwright E2E 测试并执行时使用；含写自动化前的业务熟悉踩点、Page Object/Helper 编写、执行中的 Bug 证据收集与报告条目记录。不用于：纯 API 接口测试（api-testing）、以理解系统为目的的独立探索会话（exploratory-testing）、已确认 Bug 的根因分析（bug-analysis）。.
qawolf-cli
Manage QA Wolf through the qawolf CLI. Use when asked to create, update, or list coverage requests, bug reports, or maintenance reports; start a run of flows or tags on the QA Wolf platform or read a run's results; list, set, or delete environment variables; manage environments, flows, or tags; request automation of…
api-testing
接口级测试时使用——从 OpenAPI/Swagger 文档或用例 Schema 中可自动化的接口用例出发，覆盖参数、边界、鉴权、幂等、并发、错误响应与数据一致性，产出可执行的 API 测试脚本与运行结果；含接口压测承接（k6，类型矩阵轴 1 执行层）。不用于：Web UI 流程（automated-e2e-testing）、手动用例编写（test-case-writing）。.
test-strategy
回答"这个功能应该怎么测"——把风险翻译成两域测试范围与深度。策略位于"需求 → 风险分析 → 策略 → 测试设计 → 用例"链路中，跳过策略直接写用例是本框架明确反对的。.
regression-testing
代码变更（diff/Bug 修复/需求变更）后判断应回归哪些测试时使用——沿"改动文件 → 改动函数 → 受影响功能 → 受影响用例"分析链，基于用例 Schema 的追溯映射产出分级回归清单。不用于：用例文件本身的增量修改（test-case-writing）、长期回归策略（test-strategy）。.