mcpField
G
gherkin-authoring

gherkin-authoring

github.com/intent-driven-devTesting & quality1045 installsUpdated 9w ago
Repository

About gherkin-authoring

A skill for authoring and reviewing Gherkin scenarios as concrete examples of business behavior. It helps writers keep scenarios concise, domain-focused, and centered on observable outcomes.

Key features

  1. 01Identify Gherkin within files or Markdown
  2. 02Preserve surrounding Markdown structure
  3. 03Choose suitable scenario constructs
  4. 04Keep examples concrete and concise
  5. 05Review syntax and observable outcomes

Use cases

  1. 01Draft acceptance criteria in Gherkin
  2. 02Edit a fenced Gherkin block in Markdown
  3. 03Describe behavior without UI implementation details
  4. 04Review scenarios for syntax and clarity

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/intent-driven-dev/skills --skill gherkin-authoring

After installing, type/gherkin-authoringin Claude Code to confirm it loaded.

Details

From the project README

Gherkin Authoring

Overview

Write Gherkin as executable examples of business behavior. Optimize for domain language, concrete examples, and observable outcomes; keep implementation and UI mechanics inside step definitions.

Scope

Use this for standalone .feature files and Gherkin embedded in Markdown or other prose. When Gherkin is inside a Markdown wrapper, review or rewrite only the Gherkin section unless the user asks for broader document edits. Preserve fences, headings, and surrounding prose. If the input includes Markdown around the Gherkin, return the Markdown wrapper with only the Gherkin block changed.

Workflow

  1. Identify the Gherkin region: whole .feature file, fenced gherkin block, indented block, quoted acceptance criteria, or inline scenario text.
  2. Preserve the surrounding wrapper unless explicitly asked to change it. For Markdown input, return the heading/prose/fence context, not just the fenced Gherkin block.
  3. Clarify the behavior as examples: initial state, event, observable outcome.
  4. Choose the smallest structure that expresses the behavior: Feature, optional Rule, Background, Scenario/Example, or Scenario Outline with Examples.
  5. Keep scenarios concrete and short, usually 3-5 steps.
  6. Review syntax and readability before returning: colons, step keywords, duplicate step text, observable outcomes, and table/doc string formatting.

Quick Reference

ConstructUse forSyntax note
Feature:One high-level capability per feature document or blockRequires :
Rule:Group scenarios under one business ruleRequires :
Scenario: / Example:One concrete exampleRequires :
Background:Short shared context for following scenariosRequires :; one per Feature or Rule
Scenario Outline:Same behavior with varied dataRequires Examples: and <parameter> placeholders
Examples:Data rows for an outlineRequires : and a table
GivenKnown state or preconditionNo :
WhenEvent or actionNo :
ThenObservable outcomeNo :
And / ButContinue the previous step typeNo :
*Bullet-like step listUse sparingly for list-style setup
@tagGroup or filter features/scenariosPlace above the item tagged
#Line commentLine comments only; no block comments
"""Doc StringPassed as final step argument
``Data Table

Authoring Rules

  • Use the language domain experts use. Avoid translating business behavior into UI clicks, HTTP calls, database rows, queues, mocks, or implementation details.
  • Given puts the system in a known state. Avoid user interaction in Given steps.
  • When describes one meaningful event.
  • Then describes an outcome visible to a user or external system. Do not assert hidden database state unless that is the actual external contract.
  • Use And and But to improve flow, not to hide new phases of the scenario.
  • Avoid identical step text under different step keywords; Cucumber ignores Given/When/Then when matching step definitions.
  • Use two-space indentation unless preserving existing style.
  • Keep Background short and vivid. If it grows beyond about four lines, use higher-level steps or split by Rule/Feature.
  • Use Scenario Outline only when examples share the same behavior and differ by data.
  • Escape | as \|, newline as \n, and backslash as \\ inside Data Table cells.

Example

Markdown wrapper preserved; only the Gherkin block is authored:

## Acceptance Criteria

```gherkin
Feature: Password reset
  Rule: Reset links expire after their allowed lifetime

    Scenario: Customer resets their password before the link expires
      Given Priya has requested a password reset
      And the reset link is still valid
      When Priya chooses a new password with the reset link
      Then she can sign in with the new password

    Scenario: Customer uses an expired reset link
      Given Priya has requested a password reset
      And the reset link has expired
      When Priya tries to choose a new password with the reset link
      Then she is told the reset link has expired
      And her password is unchanged
```

Common Mistakes

MistakeFix
Complaining about Markdown around a Gherkin blockPreserve the wrapper and work only on the Gherkin section.
Returning only a fenced Gherkin block when the input was MarkdownReturn the original Markdown wrapper with only the Gherkin content changed.
Feature Checkout or Scenario: Place order:Add the missing colon after Feature; remove extra colon from the scenario title.
Given I click the checkout buttonMove interaction to When; describe state in Given.
Then an order row exists in the databasePrefer an observable result, such as an order confirmation.
Reusing the same step text for Given and ThenChange the wording so the domain meaning is distinct.
Long scripts with many UI actionsRaise the abstraction and keep the scenario to the behavior.
Large Background sectionsUse higher-level context or split scenarios by Rule or Feature.

Comments

Markdown supported