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 katalon-labs/true-skills --skill analyze-failuresgit clone --depth 1 https://github.com/katalon-labs/true-skillsWrote 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/katalon-labs/true-skills/analyze-failures)<a href="https://agentmods.dev/skills/katalon-labs/true-skills/analyze-failures"><img src="https://agentmods.dev/badge/skills/katalon-labs/true-skills/analyze-failures/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/katalon-labs/true-skills/analyze-failures"><img src="https://agentmods.dev/badge/skills/katalon-labs/true-skills/analyze-failures.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.00131 | $0.00826 |
| Opus 5 | $0.00066 | $0.00413 |
| Sonnet 5 | $0.00026 | $0.00165 |
| Haiku 4.5 | $0.00013 | $0.00083 |
Grade A, and why
analyze-failures 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 12d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Katalon Analyze Failures
Use this skill for the failure-analysis part of the report/analysis stage: turn a set of failed results into a diagnosis and, when warranted, filed defects. The core value is classification — separating real product bugs from automation and environment noise.
Availability Boundary
- Available via MCP: read results (
read_test_result,read_execution_test_results,find_test_results,read_execution), defect context (fetch_defect_data), ALM discovery + filing (find_alm_integration_projects,create_defect). - Not directly available: AI root-cause summarization and automation-error-pattern analytics are TestOps/Studio product features, not MCP calls — narrate their availability, do not claim to call them.
create_defectrequires a known failed test result ID and ALM integration details; there is no ID-less defect creation.
Triage Workflow
+---------------------+ +----------------------+ +----------------------+
| Collect failures | --> | Classify each | --> | Cluster by signature |
| read results | | product/auto/env | | |
+---------------------+ +----------------------+ +----------------------+
|
v
+----------------------+
| File defects (asked) |
+----------------------+
Steps and tool rules
- Collect the failures.
find_test_results(recent/specific) orread_execution_test_resultsfor a run;read_test_resultper failed case for detail. - Classify each failure into one bucket:
- Product defect — the application behaved wrong (assertion on real behavior failed, unexpected error/state). Candidate for a filed defect.
- Automation defect — the test is wrong (bad locator, timing, stale data, broken step). Route to
test-maintenance. - Environment / data — infra, account, network, fixture, or AUT-state issue. Route to re-run after fix.
- Cluster by signature. Group failures with the same error message / step / object so one root cause is not filed as N defects.
- Check existing defects.
fetch_defect_datato avoid duplicate filings. - File defects only when asked and only for product defects.
find_alm_integration_projects->create_defectwith the failed result ID. Ask before creating unless the user explicitly requested defect filing. - Report. Per cluster: classification, likely cause, affected cases, and action (file / repair / re-run).
What ships with it
1 file 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.
- 12d ago First seen · 54 lines · 131 tokens per session scan A ab8ef5f46750
analyze-failures is a skill published in the GitHub repository katalon-labs/true-skills (8 stars, last pushed 3d ago), licensed MIT. It adds 131 tokens to every session and 826 once invoked, about $0.0007 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-31.
Other skills, from other repositories
Debugging Strategies
Advanced debugging patterns for test failures covering root cause analysis, flakiness investigation, performance debugging, and systematic troubleshooting methodologies.
Flaky Test Doctor
Diagnose flaky test failures from Playwright reports, traces, and rerun history. Classify each failure as product, test, environment, data, or unknown with cited evidence and a proposed fix. Never auto-modifies code without opt-in.
Concurrency Testing Patterns
Testing concurrent code including race condition detection, deadlock prevention, thread safety verification, and parallel execution correctness.
hotfix
Fixes an observed defect with reproducible evidence in one call: writes a short trace doc before touching code, implements the fix, and backs it with a regression test written before the fix. Production incidents are the motivating case, not a gate. When blocked, it halts by name and saves the doc for a later call to…
megalinter-check
Collect MegaLinter lint errors for the current repository. Use when the user wants to know if the code passes linting, why the MegaLinter CI job fails, or before/after fixing lint errors. Two modes - watch a CI job (GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines) and parse its logs, or run MegaLinter…
megalinter-fix
Fix the errors reported by MegaLinter. Use after megalinter-check found errors, or when the user pastes MegaLinter/CI lint errors and wants them fixed. Applies safe fixes automatically (auto-fix linters first, then guided manual fixes using per-linter fix guides), asks the user when fixing is ambiguous, and can…