CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/manual-step-to-gherkin

Translates an existing manual test step (table row, prose bullet, TestRail/Qase exported step) into a declarative Gherkin Given/When/Then step phrased in business language - strips UI mechanics ("clicks the button", "types in the field"), elevates the user intent ("signs in", "adds the product"), and aligns vocabulary with the project's existing step library. The input is an already-written manual step - not a user story and not an acceptance-criteria list. Use when a team is migrating manual test scripts to BDD, or when a manual tester is handing a script off to an automation engineer.

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, highly actionable translation ruleset with explicit validation checkpoints and clear sectioning. Its only weakness is mild verbosity in the Overview and some rule repetition across sections.

Suggestions

Tighten the Overview to state the skill's purpose in 2-3 sentences and remove the re-explanation of what imperative vs declarative Gherkin means, since the rewrite rules already demonstrate it.

Consolidate the repeated Cucumber citations into a single reference in the References section rather than restating the guidance inline in Steps 1, 2, and the Anti-patterns table.

Trim overlap between the Anti-patterns table and Steps 1-4 by keeping the table focused on failure modes and cross-linking to the relevant rule instead of restating it.

DimensionReasoningScore

Conciseness

Mostly efficient tables and rules, but the Overview re-explains the imperative-vs-declarative distinction and the Cucumber guidance is cited four times, and the Anti-patterns table restates rules already in Steps 1-4; it could be tightened without losing clarity.

2 / 3

Actionability

Concrete rewrite tables (R1, R3, R4), worked before/after examples, a specified side-by-side output format, named linters (gherkin-lint, picklesdoc), and the at-most-one-When rule give fully actionable, copy-ready guidance for an instruction-only skill.

3 / 3

Workflow Clarity

A clear four-step sequence (Classify, Apply rules, Emit, Validate) with explicit checkpoints in Step 4 - check the step library, confirm at most one When, lint, diff for semantic equivalence - and error-recovery actions (split scenarios, flag new steps for the curator).

3 / 3

Progressive Disclosure

No bundle files exist (references/scripts/assets absent); the skill is a single self-contained file with clearly signaled sections (Overview, When to use, Steps 1-4, Anti-patterns, Limitations, Hand-off targets, References) and only one-level-deep external URL/sibling-skill pointers, so organization is clean with no nested-reference problem.

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 third-person, specific, and clearly separates a narrow niche from adjacent skills while giving explicit 'Use when' triggers. It is a strong, low-conflict description with no over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete actions - "strips UI mechanics ('clicks the button', 'types in the field')", "elevates the user intent", "aligns vocabulary with the project's existing step library" - and names input formats (table row, prose bullet, TestRail/Qase exported step), matching the 'lists multiple specific concrete actions' anchor.

3 / 3

Completeness

Explicitly answers what (translates a manual step into a declarative Gherkin step, strips UI mechanics, aligns vocabulary) and when ("Use when a team is migrating manual test scripts to BDD, or when a manual tester is handing a script off to an automation engineer"), hitting the 'clearly answers both what AND when with explicit triggers' anchor.

3 / 3

Trigger Term Quality

Covers natural terms a QA engineer would say - "manual test step", "Gherkin", "TestRail/Qase", "migrating manual test scripts to BDD", and the handoff framing "manual tester is handing a script off to an automation engineer"; good coverage of terms users would naturally invoke.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (manual-step to Gherkin specifically) and actively disambiguates from siblings ("not a user story and not an acceptance-criteria list"), 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