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.
git 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/commands/katalon-labs/true-skills/analyze-failures)<a href="https://agentmods.dev/commands/katalon-labs/true-skills/analyze-failures"><img src="https://agentmods.dev/badge/commands/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/commands/katalon-labs/true-skills/analyze-failures"><img src="https://agentmods.dev/badge/commands/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.00125 | $0.01282 |
| Opus 5 | $0.00063 | $0.00641 |
| Sonnet 5 | $0.00025 | $0.00256 |
| Haiku 4.5 | $0.00013 | $0.00128 |
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 yesterday.
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 — 99 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 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.
- yesterday First seen · 99 lines · 125 tokens per session scan A ee156a138445
analyze-failures is a command published in the GitHub repository katalon-labs/true-skills (8 stars, last pushed 2d ago), licensed MIT. It adds 125 tokens to every session and 1,282 once invoked, about $0.0006 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-09-08.
Other commands, from other repositories
performance-optimization
Orchestrate end-to-end application performance optimization from profiling to monitoring.
validate-build
Validates project build process. Run after changes to ensure the project compiles/transpiles correctly.
bugfix
Bug fix workflow: root cause analysis → user review → regression test + fix via TDD.
ui-aqa-flow-test-report-analysis
Phase 7 Test Report Analysis of ui-aqa-flow.
backprop
Trace a bug back to a spec gap and generate regression tests.
fec-tdd
Use front-end TDD workflow to implement functions, fix bugs, or refactor logic: first write failing tests, then implement minimal code, and then refactor.