CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/bug-report-from-failure

On-demand builder that converts a SINGLE test failure record (JUnit XML, Allure JSON, pytest --tb=short, Playwright HTML, Cypress mocha-junit) into a structured, tracker-agnostic bug SPEC: extracts test name, assertion, stack trace, environment, and artefacts, and proposes severity, defect type (IEEE 1044), and a root-cause hypothesis (ISTQB CTAL-TA), then hands the JSON spec to a jira/linear/github-issues-bug-workflow runner to file. Use when you already hold a failure artefact and want one classified, ready-to-file report. Distinct from the event-driven CI orchestrator that triggers automatically on a pipeline failure and files in bulk, and from screen-recording-driven bug reporting; this is the on-demand, single-record spec builder.

76

Quality

96%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

100%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, lean, actionable skill body: a clear six-step workflow with a dedup gate and audit step, executable code, and clean one-level-deep references to real bundle files. It avoids teaching concepts Claude already knows and keeps detail where it belongs.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence: it never explains what JUnit/Allure/pytest are, and every section (ingest table, classification table, code blocks, anti-patterns, limitations) earns its tokens. Not the level-2 'could be tightened' case because there is no padded explanation of known concepts.

3 / 3

Actionability

Provides fully executable code for the core logic (infer_severity with its SEVERITY_FROM_ERROR map, a copy-paste worked example, a concrete file_bug dispatcher) and delegates parser bodies to real, implemented functions in references/parsers.md; the single pseudo block (find_dupes) is explicitly labelled '# Pseudo', which the rubric permits when justified.

3 / 3

Workflow Clarity

Steps 1-6 are clearly sequenced with an explicit dedup checkpoint ('Before filing, search the platform tracker' in Step 4, enforced by the 'File before deduplication' anti-pattern) and a verification/audit Step 6 ('Capture the new bug's URL', 'Append a comment', 'Update a per-test known failure register'), giving the batch-filing workflow the validation the rubric requires.

3 / 3

Progressive Disclosure

SKILL.md is an overview that points one level deep to real bundle files ([references/parsers.md] and [references/spec-template.md], both present on disk), with parser bodies and the render template appropriately split out and clearly signalled, matching the top anchor.

3 / 3

Total

12

/

12

Passed

Description

90%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A specific, complete, and highly distinctive description with strong natural trigger terms and an explicit use-when clause. The only flaw is second-person voice ('Use when you already hold'), which per the rubric costs one point of specificity.

Suggestions

Rewrite the trigger clause in third person to avoid the voice penalty, e.g. 'Use when holding a single failure artefact and needing one classified, ready-to-file report.'

Consider softening niche jargon ('tracker-agnostic bug SPEC', 'ISTQB CTAL-TA') so the description remains scannable without losing the precise capability list.

DimensionReasoningScore

Specificity

Quotes many concrete actions ('extracts test name, assertion, stack trace, environment, and artefacts', 'proposes severity, defect type (IEEE 1044)', 'hands the JSON spec to a jira/linear/github-issues-bug-workflow runner to file') which would anchor at 3, but the second-person phrasing 'Use when you already hold a failure artefact and want one classified' triggers the voice penalty, reducing the score by 1.

2 / 3

Completeness

Explicitly answers both what ('converts a SINGLE test failure record ... into a structured, tracker-agnostic bug SPEC') and when ('Use when you already hold a failure artefact and want one classified, ready-to-file report'), satisfying the top anchor.

3 / 3

Trigger Term Quality

Natural terms a user would say are well covered ('test failure record', 'bug', 'file', 'JUnit', 'Allure', 'pytest', 'Playwright', 'Cypress'), matching the 'good coverage of natural terms' anchor; the IEEE/ISTQB jargon is additive rather than crowding out the triggers.

3 / 3

Distinctiveness Conflict Risk

It carves a clear niche ('on-demand, single-record spec builder') and explicitly distinguishes itself from 'the event-driven CI orchestrator that triggers automatically on a pipeline failure and files in bulk' and 'screen-recording-driven bug reporting', making wrong-skill triggering unlikely.

3 / 3

Total

11

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents