gherkin-formatter·authoring·active

Gherkin Formatter

Renders scenarios as Cucumber-compliant Gherkin with realistic data. Tags scenarios with [EDGE] / [NEGATIVE] for downstream agents.

TARAtrigger · agent

Gherkin Formatter

Renders a list of decomposed scenarios as Cucumber-compliant Gherkin with realistic test data and downstream-friendly tagging.

When this skill fires

·Final step of TARA's authoring pipeline

·Standalone when an engineer pastes raw scenarios and asks "format this as Gherkin"

Output structure

Every scenario follows the same skeleton:

## Scenario N [TAG]: imperative title

`Given preconditions`

`When action`

`Then primary assertion`

`And additional assertions`

Tags

·[EDGE] — boundary or rare-but-real conditions

·[NEGATIVE] — intentional misuse, expected rejection

·(untagged) — happy path

EVAN's *Step Definition Generator* uses these tags to choose the right assertion patterns automatically — [NEGATIVE] flips assertions from "expect success" to "expect rejection at the validation layer".

Realistic data

The formatter never emits placeholder strings like "foo", "test@test.com", or "123". Test data is generated to look like production:

·Names from a curated list with mixed scripts and lengths

·Email addresses on plausible domains, never example.com

·Phone numbers in valid format for the implied locale

·Money amounts with realistic decimals and currency hints

→Realistic data exposes parsing bugs that placeholder data hides. A test on "O'Brien" will catch quote escaping; a test on "foo" won't.

Domain hints

The formatter reads the requirement's domain (auth, payments, search, etc.) and picks data appropriate to that domain. A payments scenario will use realistic card numbers in test ranges (4242...); an auth scenario will use mixed-case emails to exercise normalization.

What it produces

A complete # Feature block ready forEVAN's Step Definition Generator to consume:

·One ## Scenario N per scenario with the right tag

·Given/When/Then/And lines with realistic data

·A trailing comment block describing the source requirement (for traceability back to Jira/Confluence)

Example output

# Feature: User authentication with rate limiting

## Scenario 1: Successful login with valid credentials

`Given a registered user "jordan.lee@nexaq.io" with password "Valid#2026"`

`When they submit the login form`

`Then the response status is 200`

`And a session token is issued`

`And the user is redirected to /dashboard`

Related · authoring

Requirement Parser

requirement-parser

Reads ambiguous user stories, Jira tickets, or PRDs. Extracts actors, contracts, side effects, and constraints into a normalized intent graph.

Scenario Decomposer

scenario-decomposer

Breaks a normalized requirement into happy paths, edge cases, and negative paths. Anchors edge cases on real boundaries — timing, encoding, concurrency, exhaustion.

Edge Case Generator

edge-case-generator

Synthesizes non-obvious edge cases — Unicode, off-by-one, race conditions, replay attacks. Uses a curated catalog of past production incidents as priors.