open-testing-convert-opentestai

name	open-testing-convert-opentestai
description	Convert OpenTest.AI natural-language test cases (JSON with `test_steps[]`, `overall_description`, `validation_conditions`, `data.expected_test_input_parameters`, `data.expected_results`) to and from Selenium, Playwright, Cypress, Appium, Cucumber, Eggplant (SenseTalk), Testers.AI Recorder, and Testers.AI Dynamic. Handles both the dict-by-hash wrapper form `{ "<hash>": {test_case_id, name} }` and the array wrapper form `{ "test_cases": [...] }`. Use whenever the user wants to migrate an OpenTest.AI test suite, translate a single test-case object, or round-trip OpenTest.AI through another framework. MANDATORY TRIGGERS: "convert OpenTest.AI", "OpenTest.AI to Playwright", "OpenTest.AI to Selenium", "OpenTest.AI to Eggplant", "natural language tests to code", "migrate OpenTest.AI", "translate opentest", "generate Selenium from OpenTest.AI".
license	MIT
metadata	{"family":"open-testing-convert","source":"opentestai","orchestrator":"open-testing-convert","targets":["selenium","playwright","cypress","appium","cucumber","eggplant","testersai-recorder","testersai-dynamic"]}

Convert — OpenTest.AI

Converts natural-language OpenTest.AI test cases from the JSON schema to any supported target, and to OpenTest.AI from another framework. Defers orchestration, cross-framework rules, and target semantics to the open-testing-convert master skill.

When to use

Trigger when:

• The user references an OpenTest.AI test suite, .opentest.json, test_cases.json, a folder of natural-language test cases, or the OpenTest.AI format.
• The user uploads JSON with any of these shapes:
  • { "<hash1>": { "test_case_id": "...", "name": "...", "test_steps": [...] }, "<hash2>": { ... } } — dict-by-hash wrapper.
  • { "test_cases": [ { "test_case_id": "...", "test_steps": [...] } ] } — array wrapper.
  • A single bare test-case object with test_case_id, name, test_steps.
• Step lines use the imperative voice ("Navigate to ...", "Click the ...", "Verify ...", "Enter '...' into ...").
• The user asks to generate code from natural-language tests or to reverse-engineer automation from OpenTest.AI steps.

How to use

1. Read the master orchestrator first. Open ../open-testing-convert/SKILL.md.
2. Normalise the wrapper. Convert dict-by-hash and bare-object inputs into the canonical array form { "test_cases": [...] } before processing.
3. Read the OpenTest.AI target primer. ../open-testing-convert/reference/targets/opentestai.md documents the schema fields, step phrasing conventions, and the relationship to Testers.AI Dynamic.
4. Read the relevant target primer for where you're going:
   • ../open-testing-convert/reference/targets/eggplant.md
   • ../open-testing-convert/reference/targets/testersai-recorder.md
   • ../open-testing-convert/reference/targets/testersai-dynamic.md
   • For code targets: consult the per-source profile (../open-testing-convert-selenium/reference/source-profile.md, etc.) for the target's canonical shape.
5. Read this skill's reference files:
   • reference/source-profile.md — the OpenTest.AI schema, both wrapper forms, i18n, all observed field conventions.
   • reference/extraction.md — how to parse test steps into canonical intent (including NL step templates).
   • reference/mappings.md — per-target cookbook.
6. Read shared references as needed: open-testing-convert/reference/shared/{locator-mapping,wait-strategies,assertion-mapping,lifecycle-mapping}.md.
7. Emit the converted test(s) per the target primer's Emission Checklist. Produce a preamble summarising: source wrapper form, tests-converted count, language choice, any NL steps the converter couldn't pattern-match (flagged as TODOs).

Scope

• Both wrapper forms (dict-by-hash and test_cases:[] array).
• All known fields: test_case_id, name, url, overall_description, validation_conditions, test_steps, data.expected_test_input_parameters, data.expected_results, tags, priority, owner, platform, app.
• Multi-language test steps (English primary; German and other locales are preserved verbatim).
• Test cases with app context (mobile) as well as URL context (web).

Out of scope

• Testers.AI Dynamic (which shares the same step schema but uses a different envelope and adds hints[]) — use open-testing-convert-testersai-dynamic.
• Testers.AI Recorder (which uses recordedActions[]) — use open-testing-convert-testersai-recorder.

NL step → action layer — the core conversion

Natural-language targets are forgiving at execution time (an LLM resolves the step at runtime), but code targets demand concrete locators and actions. The extractor converts each NL step into a canonical action via pattern matching; ambiguous steps are flagged as TODOs.

See reference/extraction.md for the NL step template catalogue.

Quick reference: NL step → canonical

NL step pattern	Canonical
Navigate to '<url>'.	{kind:"navigate", url}
Enter '<value>' into the <field label>.	{kind:"input", locator:{label:"..."}, value}
Click the '<label>' button.	{kind:"click", locator:{role:"button", name:"..."}}
Click the <label> link.	{kind:"click", locator:{role:"link", name:"..."}}
Select '<option>' from the <field label> dropdown.	{kind:"select", locator, option}
Check the '<label>' checkbox.	{kind:"check", locator}
Hover over the '<label>' element.	{kind:"hover", locator}
Wait for the <thing> to appear.	{kind:"wait_for", kind_sub:"element_visible", ...}
Verify the URL contains '<pattern>'.	{kind:"assert", assertion_kind:"url_contains", pattern}
Verify '<text>' is visible on the page.	{kind:"assert", assertion_kind:"text_visible", value:"..."}
Verify the <field> field contains '<value>'.	{kind:"assert", assertion_kind:"value_equals", locator, value}

See reference/mappings.md for the full per-target cookbook.