CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/test-step-design-patterns

Pure reference catalog of test-step design patterns at the architecture tier - step granularity (one logical action per step), abstraction layers (mechanical → page → business), step extraction rules (when to inline / when to extract to a helper / when to extract to a Page Object method), the declarative-vs-imperative phrasing rule, FIRST principles (Fast / Independent / Repeatable / Self-validating / Timely), and the AAA / Given-When-Then mapping. This is the cross-framework architecture-tier reference for what a step IS, when it should exist, and where it should live - not file-level AAA style rules and not Gherkin-specific translation. Use when designing or reviewing the step layer of a test framework - for example when writing or reviewing E2E or integration tests, when the step count per test is high, or when refactoring recorded or codegen test output into readable steps.

80

Quality

100%

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

100%

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 dense, well-structured reference catalog with executable code, concrete heuristics, and a clearly sequenced review workflow. It keeps detail that would bloat the spine in a single properly-signaled reference file.

DimensionReasoningScore

Conciseness

A lean reference catalog - tables, code blocks, and rule heuristics with no preamble explaining concepts Claude already knows (no "what is a test step" intro). Every line teaches a rule or shows a smell/refactor pair, so each token earns its place.

3 / 3

Actionability

Concrete, copy-paste-ready TypeScript blocks for both bad (mechanical-layer) and good (business-layer) tests, plus specific numeric heuristics (>15 actions, 5+ mechanical lines, 3+ tests) that a reviewer can apply directly.

3 / 3

Workflow Clarity

The "How to use" section gives a clear seven-step sequenced audit process with explicit checkpoints - counting actions, the single-purpose split rule, the rule-of-three extraction, and a final "reader test" validation step - and the worked example walks through applying them in order.

3 / 3

Progressive Disclosure

The SKILL.md spine summarizes Patterns 5 and 6 and points to a single one-level-deep reference (references/step-grouping-and-phrasing.md) that exists and holds the full tables/code, with clear "Full ...: [references/...]" signaling.

3 / 3

Total

12

/

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 a strong, specific trigger-rich statement that clearly delineates what the catalog covers and when to invoke it, while explicitly distinguishing it from adjacent skills. It uses appropriate third-person voice and avoids fluff.

DimensionReasoningScore

Specificity

Lists multiple concrete capabilities - "step granularity (one logical action per step)", "abstraction layers (mechanical -> page -> business)", "step extraction rules", "declarative-vs-imperative phrasing rule", and "AAA / Given-When-Then mapping" - matching the multi-action anchor.

3 / 3

Completeness

Explicitly answers both what (the pattern catalog contents) and when via a literal "Use when ..." clause listing design, review, and refactoring triggers, satisfying the full-credit anchor.

3 / 3

Trigger Term Quality

Natural trigger phrasing a user would actually say - "writing or reviewing E2E or integration tests", "when the step count per test is high", "refactoring recorded or codegen test output into readable steps" - giving good coverage of common variations.

3 / 3

Distinctiveness Conflict Risk

A clear niche (architecture-tier step design) with explicit disambiguation - "not file-level AAA style rules and not Gherkin-specific translation" - making overlap with sibling skills unlikely.

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