CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/decision-table-test-design

Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.

77

Quality

97%

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

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.

An exemplary instruction-only skill body: a single worked example threaded through five sequenced steps with explicit validation and feedback loops, concrete notation and outputs throughout, and advanced material correctly offloaded to a real, clearly signaled reference file. The only weakness is minor token overhead from repeated citations and duplicated provenance dates.

Suggestions

State once in the Overview that all quoted phrases come from §4.2.3 (it nearly does this already) and drop the per-step "(§4.2.3)" / "Per §4.2.3" parentheticals to cut repeated citation tokens.

Confine version and date provenance ("2024-09-15 revision", "fetched 2026-06-10") to the References section only, removing the duplicated revision note in the Overview paragraph.

Trim the glossary.istqb.org fetch-blocked note to a single short clause or fold it into the syllabus reference line, since it does not change what the reader does.

DimensionReasoningScore

Conciseness

The body is dense with non-obvious specifics (syllabus notation T/F/`-`/N/A, the merge-legality rule, the infeasibility trap) and avoids explaining basics Claude knows, but a few tokens could be trimmed: repeated inline "(§4.2.3)" parentheticals after the Overview already declares the source, and provenance details ("2024-09-15 revision", "fetched 2026-06-10") duplicated outside the References section. Not 5 because of these minor trims and the time-sensitive date/version info not confined to a single section; not 3 because there is no padding or generic explanation.

4 / 5

Actionability

Every step is executable as written: a fully worked spec ("Premium members always ship free... express is a flat $14.99"), mechanical fill rules, exact notation, a merge test ("every expansion of the dash is feasible and produces identical actions"), and a complete output table with concrete values ("cart total $80.00", "$49.99/$50.00 around the threshold"). Not 4: the guidance covers the common cases end-to-end with no gaps a model would have to fill by guessing.

5 / 5

Workflow Clarity

Five clearly sequenced steps with an explicit validation gate in Step 4 ("R3 and R7 are infeasible; delete them") that resolves the `?` flags from Step 2, a feedback loop ("If that check fails, the table must be rebuilt with R3/R7 feasible"), and a held-merge checkpoint in Step 3 that prevents the naive R1+R3 error. Not 4: checkpoints and error-recovery paths are explicit at each decision point, not implicit.

5 / 5

Progressive Disclosure

The core derivation lives in the body while extended-entry table forms and the anti-patterns table are split into references/decision-table-details.md (verified to exist and to contain exactly what is promised), referenced one level deep under a heading that names its contents. Not 4: the split is clean, the reference is well-signaled, and nothing that belongs in the reference file is inlined.

5 / 5

Total

19

/

20

Passed

Description

100%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 model description: five concrete pipeline actions, an explicit third-person 'what', a domain-specific 'Use when' trigger clause with natural trigger terms, and explicit differentiators against each adjacent sibling skill. Every clause does distinct work with no padding or over-claiming.

DimensionReasoningScore

Specificity

Lists five concrete, sequential actions — "identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column" — plus the concrete output form ("manual step/expected cases"). Not 4: coverage spans the entire derivation pipeline with no gaps, matching the comprehensive anchor rather than 'minor gaps in coverage'.

5 / 5

Completeness

Explicitly answers what ("Derives human-readable manual test cases from a business-rule spec via a decision table") and when ("Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input") with concrete trigger phrases. Not 4: the when-clause is fully explicit and domain-specific, not merely present.

5 / 5

Trigger Term Quality

Covers the technique name ("decision table"), the domain trigger terms users would naturally say ("business-rule spec", "interacting conditions", "pricing, eligibility, discounts, routing rules"), and output vocabulary ("manual test cases", "coverage item"). Not 4: both the primary term and its natural synonyms/trigger domains are present, so no meaningful natural phrasing is missing for this domain.

5 / 5

Distinctiveness Conflict Risk

Explicitly fences off adjacent skills: "A deep single-technique walkthrough rather than a broad multi-lens case matrix", "manual step/expected cases rather than parameterized test code", "how cases are derived rather than how a case record is structured", and "rather than the boundaries of a single input". Not 4: the niche and its boundaries against every neighboring technique are stated, leaving minimal conflict risk.

5 / 5

Total

20

/

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents