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.

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 a well-sequenced, executable procedure with strong validation checkpoints and an appropriate reference split. Its main weakness is verbosity: it explains change-testing taxonomy and scope philosophy that Claude largely already knows, which could be trimmed to sharpen the actionable core.

Suggestions

Trim the 'Confirmation testing is not regression testing' section and the 'What this owns, and what it does not' framing to a couple of lines each, keeping only the scoping distinction that prevents misuse.

Replace the ISTQB glossary link prose with a one-line pointer so the conceptual context does not compete with the procedure for context-window budget.

DimensionReasoningScore

Conciseness

The procedure is accurate and largely efficient, but conceptual framing Claude largely knows (the 'Confirmation testing is not regression testing' section with ISTQB glossary links and the 'What this owns' framing) adds length that could be tightened without losing the actionable core.

2 / 3

Actionability

Provides fully executable, copy-paste-ready guidance: the `git merge-base --is-ancestor` command with a complete `case $?` block, a concrete verdict table with required evidence, and a verbatim output-shape template.

3 / 3

Workflow Clarity

Three clearly sequenced steps (prove containment, choose reproduction, verdict) with explicit validation checkpoints — the exit-code meanings, the reproduction disqualifiers, and the governing 'uncertainty resolves to BLOCKED' rule — plus a feedback loop where BLOCKED leaves the state unchanged.

3 / 3

Progressive Disclosure

SKILL.md acts as the overview, with the worked example and anti-pattern table cleanly split into the real, one-level-deep references/examples.md, signaled by a clear link. The bundle structure matches the references in the body.

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 precise, action-oriented, and well-scoped: it states concrete capabilities, gives an explicit use-when trigger, and distinguishes the skill from adjacent regression/triage activities. It uses third-person voice throughout and avoids fluff or over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete actions: 'merge-base ancestry check', 'priority order for choosing which reproduction to re-run', and the 'VERIFIED / NOT FIXED / BLOCKED verdict table', each tied to a specific procedure rather than vague language.

3 / 3

Completeness

Answers both what (the ancestry-check/reproduction/verdict procedure) and when via the explicit trigger 'Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.'

3 / 3

Trigger Term Quality

Uses natural QA terms a user would say when needing this skill: 'defect Fixed', 'moves to Verified', 'back to Reopened', and 'confirmation testing'.

3 / 3

Distinctiveness Conflict Risk

Explicitly scoped to ISTQB confirmation testing and explicitly disambiguated from regression testing and triage, giving it a clear niche 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