CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/defect-escape-taxonomy

Classifies a defect that reached production into one of three root gap categories (test gap, process gap, tooling gap) and one of thirteen sub-patterns, applying the earliest-layer rule: the category is the earliest layer that should have caught the defect, expressed as a property of the system and never of a person. Each sub-pattern carries the typical prevention fix, so the finding names an actionable class of gap. Rejects blame language and generic prevention assets such as 'add more tests'. Does not triage or prioritize the defect, does not write the missing test, and does not run a full incident postmortem. Use when a defect has been confirmed in production and the team needs to name which class of gap let it through before deciding what to build.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

85%

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

The body is highly actionable with a clear, validated workflow and well-structured progressive disclosure (one real one-level-deep reference). The only weakness is conciseness: the extended citation prose and restated boundary explanations could be trimmed without losing clarity.

Suggestions

Tighten the 'blameless constraint' and citation blocks: shorten the Google SRE/Etsy quotations to the load-bearing sentences and drop the restated boundary paragraph, since the discriminator is already given in the classification rule.

Collapse the 'Rule of thumb for the boundary that gets confused most' section into a single line under the classification rule rather than restating the test-gap/tooling-gap capability distinction a second time.

Consider moving the long ISTQB definition quotes (escaped defect, root cause, quality gate) into the references file so the body keeps only the rule each definition justifies.

DimensionReasoningScore

Conciseness

The body is mostly efficient and well-organized, but several paragraphs teach framing beyond the minimum actionable instruction — extended SRE/Etsy quotes and a restated test-gap/tooling-gap boundary ('Rule of thumb for the boundary that gets confused most') that could be tightened. It is not padded with basics Claude lacks, so it stays above 1, but the explanatory prose keeps it below the lean 3 anchor.

2 / 3

Actionability

Guidance is fully concrete and executable: a 7-step Procedure, sub-pattern→fix tables, an executable TypeScript vitest example, and a specific blame-scan keyword list. This matches the copy-paste-ready 3 anchor rather than the pseudocode/incomplete 2 anchor.

3 / 3

Workflow Clarity

The 7-step Procedure is clearly sequenced with explicit validation checkpoints — Step 6 verifies the asset fails against the introducing commit, and Step 7 is a blame-scan rewrite loop — providing the feedback loop the 3 anchor requires. Checkpoints are explicit, not implicit, so it is above 2.

3 / 3

Progressive Disclosure

The body serves as the overview and the per-defect document template is split into references/escape-defect-document-template.md, linked one level deep with a clear inline pointer in 'Expected output shape' (verified the file exists). This matches the well-signaled one-level-deep 3 anchor.

3 / 3

Total

11

/

12

Passed

Description

100%

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

The description is specific, complete, and distinctive: it states concrete capabilities, includes an explicit 'Use when' trigger, and draws clear boundaries against triage, test-writing, and postmortem skills. It is a strong, low-conflict description with no significant weaknesses.

DimensionReasoningScore

Specificity

Names multiple concrete actions — three root gap categories (test/process/tooling gap), thirteen sub-patterns, the earliest-layer rule, and the rejection of blame language and generic assets — all in third person. It is comprehensive rather than naming only a domain and partial actions, so it sits above the 2 anchor.

3 / 3

Completeness

Explicitly answers both what (classifies an escaped defect into category + sub-pattern with prevention fix) and when ('Use when a defect has been confirmed in production and the team needs to name which class of gap let it through'). The explicit 'Use when' clause satisfies the 3 anchor rather than capping at 2.

3 / 3

Trigger Term Quality

Natural terms a user would say are well covered ('defect', 'reached production', 'confirmed in production', 'postmortem', 'triage') alongside the explicit 'Use when' trigger. Some jargon ('earliest-layer rule', 'sub-patterns') appears, but overall natural-keyword coverage is strong, matching the 3 anchor.

3 / 3

Distinctiveness Conflict Risk

It carves a clear niche (escaped-defect classification) and an explicit non-owns list ('Does not triage... does not write the missing test... does not run a full incident postmortem') that separates it from adjacent skills, so it is unlikely to trigger for the wrong skill.

3 / 3

Total

12

/

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