open-testing-convert-gauge

name	open-testing-convert-gauge
description	Convert Gauge test specs (Markdown `.spec` + `.cpt` concept files, `manifest.json`, `env/default/*.properties`, `gauge.properties`) and language step files — Java `@Step`, C# `[Step]`, Python `@step`, JS `step()`, Ruby `step`, Go `gauge.Step`. Handles scenarios (`## Name`), steps (`* Step <param>`), pipe-delimited tables, `<placeholder>` / `<file:>` / `<table:>` bindings, hooks (`@BeforeSpec` / `@AfterScenario` / `@BeforeStep`), data stores (Suite/Spec/ScenarioDataStore), `Gauge.writeMessage`, `Gauge.captureScreenshot`, language plugins (gauge-java/csharp/js/python/ruby/go), parallel runner, tag expressions. Targets: Selenium, Playwright, Cypress, Cucumber, Appium, Taiko, Robot Framework, SpecFlow, Karate, Eggplant, OpenTest.AI, Testers.AI. MANDATORY TRIGGERS: "convert Gauge", "Gauge to <target>", "getgauge", ".spec file", ".cpt file", "gauge-java".
license	MIT
metadata	{"family":"open-testing-convert","source":"gauge","orchestrator":"open-testing-convert","targets":["selenium","playwright","cypress","webdriverio","puppeteer","appium","cucumber","eggplant","testcafe","nightwatch","codeceptjs","taiko","protractor","katalon","playwright-bdd","behave","specflow","behat","karate","robot-framework","opentestai","testersai-recorder","testersai-dynamic"]}

Convert — Gauge

Converts Gauge's Markdown-based test specifications to any supported target, and emits Gauge from any source.

Gauge (from ThoughtWorks) is superficially similar to Cucumber but architecturally different in three ways that matter for extraction:

1. Specs are Markdown. A .spec file is valid Markdown with conventional semantic meaning attached to headings, bullets, and tables. The H1 is the spec title; H2s are scenarios; bullet items (* ...) are steps; tables directly below steps are arguments.
2. Steps are language-implemented, not pattern-matched at runtime. Gauge language plugins statically bind step text to annotated functions (@Step("...") in Java, etc.). Step text can contain <placeholder> tokens which bind to named parameters.
3. Concepts (.cpt) are multi-step step aliases. A concept defines a single "step" that expands to an ordered list of sub-steps — closer to Robot Framework user keywords than to Cucumber's step definitions.

When to use

Trigger when:

• manifest.json with "Language" field at project root.
• .spec or .cpt files alongside env/, logs/, reports/ directories.
• gauge.properties present.
• Step implementation files with @Step(...) (Java), [Step(...)] (C#), @step(...) (Python), step(...) call (JS/Ruby), or gauge.Step(...) (Go) decorators.
• CI commands like gauge run specs/, gauge run --tags, mvn test -Pgauge.
• Dependency on com.thoughtworks.gauge:gauge-java, getgauge (npm), getgauge/python, gauge-ruby, or Gauge.CSharp.Lib.
• Project uses Gauge + Taiko (common JS web-testing combo) or Gauge + Selenium (JVM).

How to use

1. Read the master orchestrator first.
2. Read this skill's reference files: source-profile.md, extraction.md, mappings.md.
3. Read target primer for your target.
4. Emit per target Emission Checklist.

Scope

• Gauge core 1.x (current at time of writing).
• Language plugins: Java, C#, Python, JavaScript, Ruby, Golang.
• .spec files with H1 spec title, tag block, optional spec-level context steps, H2 scenarios, bullet steps, tables, and step/scenario tags.
• .cpt concept files and concept expansion.
• Hooks with tag filters: @BeforeSpec / @AfterSpec / @BeforeScenario / @AfterScenario / @BeforeStep / @AfterStep / @BeforeSuite / @AfterSuite.
• Tags: spec-level (in spec header) and scenario-level.
• Dynamic table parameters (Markdown pipe tables feeding <col> placeholders).
• Special parameters: <file:path>, <table:path>.
• Data stores: SuiteDataStore / SpecDataStore / ScenarioDataStore.
• env/default/*.properties and env-switching (gauge run --env ci).
• Parallel execution flag (--parallel -n), data-stream parallelism.
• Tag expression syntax ((a & !b) | c).
• Taiko integration (Gauge-JS canonical web stack).
• Selenium, Appium, Playwright step library patterns.

Out of scope

• Gauge LSP server internals — extraction-irrelevant.
• HTML-report customisation (custom CSS / template) — preserve as todo.
• spectacle / screenshot-on-failure plugins — mapped as boolean flags.
• Proprietary gauge-screenshot-js config — preserve as-is, best-effort.
• Bespoke gauge-plugin binary extensions (written in Go) — flag as todo.

Quick reference

Gauge construct	Canonical	Example target
# Login Spec (H1)	feature: {title: "Login Spec"}	Cucumber Feature: Login Spec
Tags: smoke, login (spec-level)	feature_tags: ["smoke", "login"]
## Valid login (H2)	scenario: {title: "Valid login"}	Cucumber Scenario: Valid login
* Login as "alice"	{kind: "step", text: "Login as \"alice\"", params: [{value: "alice"}]}	step def invocation
<username> placeholder	{kind: "step", params: [{ref: "username"}]}	parameterised
* Login as <user> with table below	data_driven: {columns: ["user"], rows: [...]}	Scenario Outline
* Read data from <table:users.csv>	{kind: "data_load", source: "users.csv"}	load fixture
@BeforeScenario(tags = "smoke")	hook: {phase: "before_scenario", tag_filter: ["smoke"]}	Before('@smoke')
login.cpt concept file	concepts: {name, expansion: [...steps]}	inlined or step helper
ScenarioDataStore.put("k", v)	{kind: "state_set", scope: "scenario", name: "k", value: v}	fixture/world

See reference/mappings.md for full cookbook.