CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/confirmation-testing-workflow

Procedure for proving that a claimed defect fix actually reached the build under test and actually works. Covers the merge-base ancestry check that proves the running build contains the fix commit rather than trusting a version label, the priority order for choosing which reproduction to re-run, and the VERIFIED / NOT FIXED / BLOCKED verdict table whose governing rule is that any ambiguous, flaky, or unreproducible result resolves to BLOCKED and is never guessed. Scoped to ISTQB confirmation testing (does this specific fix work?), not regression testing (did the fix break something else?), and not triage or severity assignment. Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.

99

1.03x
Quality

94%

Does it follow best practices?

Impact

100%

1.03x

Average score across 10 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

92%Weight 40%Scale 1-5

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

A well-structured, actionable procedure with explicit validation checkpoints and appropriate offloading of examples to a real one-level reference. Marginally verbose in a few explanatory passages but otherwise excellent.

DimensionReasoningScore

Conciseness

Dense procedural content with copy-paste code and tables rather than padding, but the confirmation-vs-regression framing and some 'common error' exposition could be trimmed slightly; not a 5 only because a few passages over-explain.

4 / 5

Actionability

Provides a copy-paste-ready `git merge-base --is-ancestor` bash snippet with a full exit-status case statement, a concrete verdict table with evidence requirements, and a fill-in output template — fully executable guidance covering the common cases.

5 / 5

Workflow Clarity

Three explicitly sequenced steps (prove containment, choose reproduction, verdict) with an upfront validation checkpoint (the ancestry check), explicit error-recovery handling (errored check resolves to BLOCKED, not MISSING), and a governing rule that acts as a checklist for ambiguous results.

5 / 5

Progressive Disclosure

Core procedure lives inline under clear section headers; the worked example and anti-pattern table are split into a single one-level-deep reference at references/examples.md, which exists and is clearly signaled with a markdown link.

5 / 5

Total

19

/

20

Passed

Description

92%Weight 40%Scale 1-5

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 highly specific, well-scoped description that answers what and when concretely and distinguishes itself from sibling testing skills. Only minor gap is a few natural synonyms (retesting, reproduce) that users might invoke.

DimensionReasoningScore

Specificity

Names multiple concrete components — 'the merge-base ancestry check', 'the priority order for choosing which reproduction to re-run', and 'the VERIFIED / NOT FIXED / BLOCKED verdict table' — giving comprehensive coverage of what the procedure does rather than vague abstraction.

5 / 5

Completeness

Explicitly answers both 'what' (the proof procedure and its three components) and 'when' (a developer has marked a defect Fixed and a Verified-vs-Reopened decision is needed) with concrete trigger phrases.

5 / 5

Trigger Term Quality

Strong natural trigger phrasing ('Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened') plus ISTQB terms, but misses common synonyms a user might say like 'retesting' or 'reproduce the bug'.

4 / 5

Distinctiveness Conflict Risk

Explicit scoping — 'Scoped to ISTQB confirmation testing... not regression testing... and not triage or severity assignment' — carves a clear niche with minimal overlap risk against adjacent skills.

5 / 5

Total

19

/

20

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