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 skills add akovalion/paranoid-qa --skill testinggit 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/testing)<a href="https://agentmods.dev/skills/akovalion/paranoid-qa/testing"><img src="https://agentmods.dev/badge/skills/akovalion/paranoid-qa/testing/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/akovalion/paranoid-qa/testing"><img src="https://agentmods.dev/badge/skills/akovalion/paranoid-qa/testing.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00085 | $0.09803 |
| Opus 5.5 | $0.00034 | $0.03921 |
| Sonnet 5.5 | $0.00017 | $0.01961 |
| Haiku 4.5 | $0.00009 | $0.00980 |
Grade A, and why
testing scanned grade A with 1 finding 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 8d 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- **КРАСНЫЙ ФЛАГ: инструмент и браузер расходятся при идентичном запросе.** curl/API-клиент даёт 200, а браузер — 5xx, payload и заголовки совпадают побайтово → в 99% случаев это твой перехват, а не дефект. **Первым дело How it starts
The opening of the file, as written. The whole thing — 174 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Мастер-чеклист «как тестировать что угодно» — frontend/UI и backend/сервисы. Доктрина:
- Дотошность по умолчанию. Покрывай всё сам: happy path → негатив → границы → редкие комбинации. Глубина пропорциональна риску, но классы проверок не пропускай.
- Доказательность. Pass/Fail ставится ТОЛЬКО по наблюдённому артефакту (скриншот, ответ сети, лог, дамп БД). Не проверял —
Not tested, помешали —Blockedс причиной. Никаких галлюцинаций и «по логике должно работать». - Логируй каждое отклонение сразу. Любое расхождение с макетом/требованиями фиксируй немедленно, даже минорное (отступ, копирайт, цвет).
- Цель — заменить ручное тестирование. Надёжность важнее скорости; «не успел/не смог» пишем прямо.
0. Процесс (для любой задачи)
Сбор контекста
- Прочитать тикет целиком: описание, AC/Gherkin, комментарии, вложения, связанные задачи (blocks/relates/epic), компонент, релиз.
- Каждое вложение открыть и прочитать, а не принять к сведению по имени файла. docx/pdf/xlsx - извлечь текст (zip + XML, pdftotext, openpyxl), картинки - посмотреть глазами. Wiki-страницы и ТЗ по ссылкам из тикета - вместе с их вложениями и страницами, на которые они ссылаются (определения параметров, справочники).
- В первом ответе пользователю перечислить прочитанные источники («тикет, 2 комментария, 2 docx, страница ТЗ + 2 скриншота, 2 связанные страницы»). Что не открылось или не прочитано - сказать сразу с причиной, а не после вопроса «а файлы ты смотрел?».
- Зафиксировать source of truth для каждого требования (AC → ТЗ/Confluence → Figma → прод-поведение) и приоритет при конфликте.
- Сверить Figma: версия, режим (desktop/mobile/adaptive), states (default/hover/focus/active/disabled/loading/error/empty), варианты компонентов, токены; что в макете vs что «подразумевается».
- Найти существующие ТК (в вашей TMS — Zephyr/TestRail/др.) и автотесты (в репозитории автотестов проекта): переиспользовать, выявить пробелы, не дублировать. Статусам TMS не верить слепо — сверять с живыми тестами: встречаются «Automated» без существующего автотеста и «требуется автоматизация» на давно покрытом.
- Снять прод/preprod baseline (как фича работает сейчас — для регрессии и воспроизведения багов на актуальной версии).
- Уточнить окружение: стенд, доступы, тестовые учётки/роли, фиче-флаги, состояние данных, версия билда/коммит.
- Определить интеграции и зависимости: внешние API, платёжки, авторизация, очереди — что мокается, что реально.
- Явно зафиксировать out of scope (нативные приложения, неподдерживаемые браузеры, легаси-флоу).
Анализ требований и вопросы аналитику
- Каждый AC → проверка; каждая проверка → ссылка на AC или явная пометка «доп. эвристика».
- Когда скоуп = конкретное ТЗ: вердикты Pass/Fail только по его пунктам; находки вне ТЗ — отдельным блоком «вне скоупа» (наблюдение/вопрос), не Fail и не дефект задачи.
- Выявить неоднозначности («должно корректно работать», нет конкретных значений, неуказанные границы, неопределённое поведение при ошибке).
- Расхождения тикет ↔ Figma ↔ прод ↔ доку — НЕ закрывать допущением, выписать вопросом.
- Зафиксировать неопределённое поведение: пустые состояния, ошибки сети/сервера, таймауты, отказ интеграции, параллельные действия, истёкшая сессия.
- Уточнить: валидации (обязательность, форматы, маски, длины, допустимые символы, клиент vs сервер, тексты ошибок); права/роли (кто видит/может, неавторизованный, без permission); локаль/форматы (язык, дата/время/валюта/числа, TZ, направление текста).
- Все вопросы — списком с пометкой блокирующий/неблокирующий; блокирующие закрыть до старта.
Приоритизация и риск
- Риск по областям = вероятность дефекта × влияние (деньги, безопасность, данные, репутация, частота использования).
- Фокус на изменённом коде и его blast radius, а не ровным слоем.
- Решить: что автоматизировать (стабильное, регрессоопасное) vs ручная проверка (разведка, UX, разовое, визуал).
- Выделить smoke-подмножество (критичное для быстрой проверки билда) и regress-подмножество.
- Под дедлайн договориться о глубине явно, а не молча урезать.
What ships with it
6 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 8d ago Changed · +2 lines 551e9567b0a2
- 11d ago Changed · +11 lines f6ed01f65f62
- 23d ago Changed e4eafef5fe96
- 24d ago Changed 38dcfc28d8f5
- 1mo ago Changed · +1 lines daef60096322
- 1mo ago First seen · 160 lines · 85 tokens per session scan A c5a7eaa61ee3
testing is a skill published in the GitHub repository akovalion/paranoid-qa (15 stars, last pushed 9d ago), licensed MIT. It adds 85 tokens to every session and 9,803 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). 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…
qa-testing
Run QA testing on a page, feature, or full site at one of three depth tiers (smoke, standard, full). Use this skill whenever the user asks to QA a page or site, run a smoke test after a deploy, verify a page before launch, or run a regression sweep. Triggers on QA, QA sweep, smoke test, regression test, post-deploy…
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; run or list flows…
automated-e2e-testing
A workflow for turning manual web-app test cases into Playwright end-to-end tests and running them. End-to-end tests check a complete user flow through the website.
qa-expert
Expert-level quality assurance, testing strategies, automation, and QA processes. Use when the user mentions testing, test automation, quality assurance, or Selenium, or when the task involves Testing Types, QA Processes, Test Strategy, or Defect Management.
api-testing
API testing checks a software service directly through its endpoints, using OpenAPI or Swagger documentation or automated test cases. It can produce and run scripts that test requests and responses.