evizi-kit 1.0.0

package/kits/shared/skills/web-auto-test-cases/evals/evals.json

@@ -0,0 +1,129 @@
+{
+  "skill_name": "web-auto-test-cases",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Create test cases for ticket FE-2026. Here's the ticket content:\n\n- Feature: Administration - Users Monitors\n- Related Feature: None\n\n## Ticket Information\n\n### TC057\n**Summary:** Successfully add a new user with all required fields\n**Preconditions:** Admin user is logged in. Navigate to Administration > Users Monitors page.\n**Test Data:** Username: testuser01, Email: testuser01@example.com, Role: Viewer\n**Steps:**\n1. Click the 'Add User' button\n2. Fill in Username field with 'testuser01'\n3. Fill in Email field with 'testuser01@example.com'\n4. Select Role 'Viewer'\n5. Click 'Save'\n**Expected Results:**\n1. New user appears in the users list\n2. Success toast notification is shown\n**Post-conditions:** Delete the newly created user testuser01\n\n### TC058\n**Summary:** Show validation error when email is missing\n**Preconditions:** Admin user is logged in. Navigate to Administration > Users Monitors page. 'Add User' dialog is open.\n**Test Data:** Username: testuser02\n**Steps:**\n1. Fill in Username field with 'testuser02'\n2. Leave Email field empty\n3. Click 'Save'\n**Expected Results:**\n1. Error message 'Email is required' appears below the Email field\n2. User is not created\n**Post-conditions:** None",
+      "expected_output": "A test-cases.md file at .tickets/FE-2026/test-cases.md containing a Gherkin feature with @FE-2026 tag, exactly 2 scenarios tagged @TC057 and @TC058 respectively, @TC057 having @cleanup tag, @TC058 not having @cleanup, Background with the shared admin/navigation precondition, and all test data values in double quotes.",
+      "assertions": [
+        {
+          "id": "a1",
+          "name": "output file created at correct path",
+          "description": "The file .tickets/FE-2026/test-cases.md exists"
+        },
+        {
+          "id": "a2",
+          "name": "feature tag is exact ticket ID",
+          "description": "File contains @FE-2026 as a feature-level tag"
+        },
+        {
+          "id": "a3",
+          "name": "both test case IDs present as scenario tags",
+          "description": "File contains both @TC057 and @TC058 as scenario tags"
+        },
+        {
+          "id": "a4",
+          "name": "cleanup tag on TC057 only",
+          "description": "@cleanup tag appears on TC057 scenario; TC058 scenario does not have @cleanup"
+        },
+        {
+          "id": "a5",
+          "name": "no related feature tag",
+          "description": "No extra feature tag beyond @FE-2026 (since Related Feature is None)"
+        },
+        {
+          "id": "a6",
+          "name": "variable data in double quotes",
+          "description": "Test data values like testuser01, testuser01@example.com appear in double quotes in step text"
+        },
+        {
+          "id": "a7",
+          "name": "background contains shared precondition",
+          "description": "Background section includes admin login and navigation setup shared by both test cases"
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Generate BDD scenarios for ticket REPORT-014:\n\n- Feature: Reports - Monthly Sales\n- Related Feature: dashboard\n\n## Ticket Information\n\n### TC101\n**Summary:** Export monthly sales report as CSV\n**Preconditions:** User is logged in with Report Viewer role. Monthly sales data exists for January 2025.\n**Test Data:** Month: January 2025, Format: CSV\n**Steps:**\n1. Navigate to Reports > Monthly Sales\n2. Select 'January 2025' from the month picker\n3. Click 'Export' button\n4. Select 'CSV' format from dropdown\n5. Click 'Download'\n**Expected Results:**\n1. File download starts automatically\n2. Downloaded file name is 'monthly-sales-2025-01.csv'\n3. File contains correct sales data for January 2025\n**Post-conditions:** None\n\n### TC102\n**Summary:** Show empty state message when no data available\n**Preconditions:** User is logged in with Report Viewer role. No sales data exists for the selected period.\n**Test Data:** Month: February 2024\n**Steps:**\n1. Navigate to Reports > Monthly Sales\n2. Select 'February 2024' from the month picker\n**Expected Results:**\n1. Page displays message 'No sales data available for the selected period'\n2. Export button is disabled\n**Post-conditions:** None\n\n### TC103\n**Summary:** Filter report by sales region\n**Preconditions:** User is logged in with Report Viewer role. Monthly sales data exists with multiple regions.\n**Test Data:** Month: March 2025, Region: North America\n**Steps:**\n1. Navigate to Reports > Monthly Sales\n2. Select 'March 2025' from the month picker\n3. Apply filter 'North America' from Region dropdown\n**Expected Results:**\n1. Report data updates to show only North America sales\n2. Total sales figure reflects North America only\n**Post-conditions:** None",
+      "expected_output": "A test-cases.md file at .tickets/REPORT-014/test-cases.md with @REPORT-014 and @dashboard feature tags, feature line 'Feature: Reports - Monthly Sales', exactly 3 scenarios tagged @TC101, @TC102, @TC103, no @cleanup on any scenario, Background with the shared 'logged in with Report Viewer role' precondition, and test data values in double quotes.",
+      "assertions": [
+        {
+          "id": "a1",
+          "name": "output file at correct path",
+          "description": "File .tickets/REPORT-014/test-cases.md exists"
+        },
+        {
+          "id": "a2",
+          "name": "both feature tags present",
+          "description": "@REPORT-014 and @dashboard both appear as feature-level tags"
+        },
+        {
+          "id": "a3",
+          "name": "feature line correct",
+          "description": "Feature line reads 'Feature: Reports - Monthly Sales'"
+        },
+        {
+          "id": "a4",
+          "name": "all three scenario IDs present",
+          "description": "@TC101, @TC102, and @TC103 all appear as scenario tags"
+        },
+        {
+          "id": "a5",
+          "name": "no cleanup tag on any scenario",
+          "description": "@cleanup does not appear anywhere in the file (all Post-conditions are None)"
+        },
+        {
+          "id": "a6",
+          "name": "shared precondition in background",
+          "description": "Background contains the Report Viewer login precondition shared by all scenarios"
+        },
+        {
+          "id": "a7",
+          "name": "month/region values in double quotes",
+          "description": "Values like 'January 2025', 'North America', 'monthly-sales-2025-01.csv' appear in double quotes in step text"
+        }
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "write gherkin test cases for ticket AUTH-007:\n\n- Feature: Authentication - Login\n- Related Feature: None\n\n## Ticket Information\n\n### TC201\n**Summary:** Successful login with valid credentials\n**Preconditions:** User account exists with username 'qa_tester' and password 'Test@1234'. User is on the login page.\n**Test Data:** Username: qa_tester, Password: Test@1234\n**Steps:**\n1. Enter 'qa_tester' in the Username field\n2. Enter 'Test@1234' in the Password field\n3. Click 'Login' button\n**Expected Results:**\n1. User is redirected to the dashboard\n2. Welcome message displays 'Welcome, qa_tester'\n**Post-conditions:** Log out the user\n\n### TC202\n**Summary:** Login fails with incorrect password\n**Preconditions:** User is on the login page.\n**Test Data:** Username: qa_tester, Password: WrongPass\n**Steps:**\n1. Enter 'qa_tester' in the Username field\n2. Enter 'WrongPass' in the Password field\n3. Click 'Login' button\n**Expected Results:**\n1. Error message 'Invalid username or password' is displayed\n2. User remains on the login page\n**Post-conditions:** None",
+      "expected_output": "A test-cases.md file at .tickets/AUTH-007/test-cases.md with @AUTH-007 feature tag, no related feature tag, exactly 2 scenarios @TC201 (with @cleanup) and @TC202 (without @cleanup), only the 'User is on the login page' precondition in Background (shared by both), with TC201's unique user-account precondition as a Given step inside its scenario, and credentials in double quotes.",
+      "assertions": [
+        {
+          "id": "a1",
+          "name": "output file at correct path",
+          "description": "File .tickets/AUTH-007/test-cases.md exists"
+        },
+        {
+          "id": "a2",
+          "name": "correct feature tag only",
+          "description": "@AUTH-007 present, no other feature-level tag (Related Feature is None)"
+        },
+        {
+          "id": "a3",
+          "name": "TC201 has cleanup, TC202 does not",
+          "description": "@TC201 scenario has @cleanup tag; @TC202 does not"
+        },
+        {
+          "id": "a4",
+          "name": "TC201 unique precondition in scenario Given",
+          "description": "The 'User account exists' precondition appears as a Given step inside TC201's scenario, not in Background"
+        },
+        {
+          "id": "a5",
+          "name": "shared login page precondition in background",
+          "description": "Background contains the 'User is on the login page' precondition"
+        },
+        {
+          "id": "a6",
+          "name": "credentials in double quotes",
+          "description": "Values like qa_tester, Test@1234, WrongPass appear in double quotes in step text"
+        }
+      ],
+      "files": []
+    }
+  ]
+}

package/kits/shared/skills/web-auto-test-cases/templates/test-cases.template.md

@@ -0,0 +1,53 @@
+# Test Cases Template
+
+Use this template as the output structure for `test-cases.md`.
+
+```gherkin
+@{ticket-tag}
+@{related-feature-tag-if-applicable}
+Feature: {PARENT_FEATURE} - {CHILD_FEATURE}
+
+  Background:
+    Given {common precondition shared across all test cases}
+    And {additional setup}
+
+  @{exact-test-case-id} @cleanup
+  Scenario: {descriptive name from summary}
+    When {action from Steps section}
+    And {additional action}
+    Then {expected result from Expected Results section}
+    And {additional expectation}
+
+  @{exact-test-case-id-2}
+  Scenario: {descriptive name from summary}
+    Given {unique precondition for this scenario only}
+    When {action from Steps section}
+    Then {expected result}
+```
+
+## Feature Level
+
+| Element | Rule |
+|---------|------|
+| Feature tag | `@{TICKET_ID}` — exact ticket ID |
+| Related Feature tag | `@{related-feature}` — only if present and not "None" |
+| Feature line | `Feature: {PARENT_FEATURE} - {CHILD_FEATURE}` — exact values from ticket instructions |
+| Background | Common preconditions shared across all test cases |
+
+## Scenario Level
+
+| Element | Rule |
+|---------|------|
+| Scenario tag | Exact Test Case ID (e.g., `@TC057`) — never generic tags |
+| `@cleanup` tag | Only when that test case's Post-conditions require it |
+| Scenario name | Derived from the test case's Summary |
+
+## Step Translation
+
+| Source | Gherkin Keyword |
+|--------|----------------|
+| Steps section | `When` / `And` |
+| Expected Results | `Then` / `And` |
+| Unique preconditions | `Given` (within the scenario) |
+| Test Data values | Enclosed in double quotes |
+| Variable data (emails, names, messages) | Enclosed in double quotes |

package/kits/shared/skills/web-auto-ticket-design/SKILL.md

@@ -0,0 +1,199 @@
+---
+name: web-auto-ticket-design
+description: Transform BDD Gherkin test cases into a comprehensive test design document with actionable test steps. Reads test-cases.md, deeply searches the codebase for reusable Page Objects, elements, and API helpers, then generates ticket-design.md mapping every Gherkin step to concrete actions. Use this skill whenever someone asks to create a ticket design, generate a test design, transform Gherkin into test steps, translate BDD scenarios into implementation-ready steps, or bridge test cases to code — even if the request is phrased casually like "design the test steps" or "what do I need to implement for this ticket". Triggers on requests like "create ticket design for TKT-001", "generate test design for ABC-123", "design test steps for ticket fe-2026", "turn these scenarios into test steps", or "map Gherkin to page objects".
+---
+
+# Web Automation Ticket Design
+
+Read a `test-cases.md` file for a given ticket ID, search the codebase for reusable Page Objects and elements, and transform Gherkin scenarios into a detailed test design document saved as `ticket-design.md`.
+
+The purpose of this skill is to bridge the gap between BDD scenarios (what to test) and implementation (how to test it). A good ticket design tells the downstream Playbook and Coding skills exactly which existing code to reuse and where new code is needed — saving significant implementation time.
+
+## Input Parameters
+
+| Parameter | Type | Required | Description |
+|-----------|------|----------|-------------|
+| `TICKET_ID` | string | Yes | The ticket identifier (e.g., TKT-001, ABC-123) |
+
+**If `TICKET_ID` is not provided:** Ask the user for the ticket ID before proceeding.
+
+## Workflow
+
+### Step 1: Locate and Read Test Cases
+
+Search for the test cases file using this glob pattern:
+
+```
+.tickets/{TICKET_ID}/test-cases.md
+```
+
+**If not found:** Inform the user and stop:
+
+```
+Error: test-cases.md not found for ticket {TICKET_ID}.
+Run the web-auto-test-cases skill first to create it.
+```
+
+**If found:** Read the entire file and extract:
+- **Feature / Child Feature** from the Feature line
+- **Related Feature** from the related feature tag (if not "None")
+- **Test Case IDs** from scenario tags (e.g., `@TC001`, `@TC057`)
+- **Background steps** — shared preconditions that apply to all scenarios
+- **Key actions** mentioned in Gherkin steps (navigate, click, enter, verify, select, toggle, etc.)
+- **Key elements** mentioned (buttons, fields, dropdowns, tables, modals, etc.)
+- **Quoted test data** — all values in double quotes (emails, usernames, amounts, dates, etc.), since these will appear as parameters in the design steps
+- **Cleanup tags** — scenarios tagged with `@cleanup` need teardown steps
+
+### Step 2: Search and Catalog Source Code
+
+Search the test automation codebase for existing Page Objects, actions, and elements. Complete all analysis internally — do not output to the user.
+
+The goal here is maximizing code reuse. Every existing method or element you find means one fewer thing the implementer needs to build from scratch. Invest the time in thorough searching — it pays off significantly downstream.
+
+**2.1 — Search for Page Objects**
+
+Start broad, then narrow down. Search in this order:
+
+| Priority | Search Target | Patterns |
+|----------|---------------|----------|
+| 1 | Feature Page Objects | `class [Feature]Page`, `[feature].page.ts`, `[feature]-page.ts`, `[feature].po.ts` |
+| 2 | Related Feature Page Objects | Classes for the Related Feature (if applicable) — these often share elements |
+| 3 | Shared / Base Page Objects | `BasePage`, `CommonPage`, `SharedPage`, navigation helpers, header/footer components |
+| 4 | API / Data Helpers | `Api`, `Helper`, `Factory`, `Service`, `Client` — classes for CRUD operations and data setup |
+
+Read discovered Page Object files to understand their full API (methods and elements), not just that they exist.
+
+**2.2 — Search for Elements and Actions**
+
+For each key element and action identified in Step 1, search for:
+- Element locators: `getByTestId`, `getByRole`, `getByLabel`, `getByText`, `locator`, `readonly`
+- Action methods: method signatures matching the action (e.g., `async fill`, `async click`, `async select`, `async navigate`)
+- Selectors: `[data-testid="..."]`, `#element-id`, `.class-name`
+- API methods: `async create`, `async delete`, `async update`, `async get` — for CRUD operations in Background/Given steps
+
+**2.3 — Catalog Findings**
+
+Build internal reference tables (these help ensure consistent mapping in Step 3):
+
+```
+Available Actions:
+| Action | Method | Source File |
+|--------|--------|-------------|
+
+Available Elements:
+| Element | Reference | Source File |
+|---------|-----------|-------------|
+
+Available API Helpers:
+| Operation | Method | Source File |
+|-----------|--------|-------------|
+```
+
+**2.4 — Plan Transformations**
+
+For each Gherkin step, determine:
+- Which existing resources (actions/elements/API helpers) to use
+- Which step format (1, 2, 3, or 4) applies — see the format selection guide below
+
+Do not proceed to Step 3 until planning is complete for every step.
+
+### Step 3: Transform Gherkin Steps
+
+Transform each Gherkin step using the appropriate format from the template at [templates/ticket-design.template.md](templates/ticket-design.template.md).
+
+#### Format Selection Guide
+
+Use this decision tree to pick the right format for each step:
+
+```
+Is this step an API/data operation (CRUD, setup, teardown, service call)?
+├── Yes → Does a matching API method exist?
+│   ├── Yes → Format 1 (existing API action)
+│   └── No  → Format 4 (new API action needed)
+└── No (it's a UI interaction) → Does a matching action method exist?
+    ├── Yes → Format 1 (existing UI action)
+    └── No  → Does the element exist (locator defined)?
+        ├── Yes → Format 2 (element exists, no action method)
+        └── No  → Format 3 (new UI implementation needed)
+```
+
+Quick summary of the four formats:
+- **Format 1** — Complete action method found (UI or API). No Element/Selector lines needed.
+- **Format 2** — Element locator exists but no dedicated action method. UI interactions only.
+- **Format 3** — Nothing found — new UI implementation needed. Uses `<-- Update selector for this element -->` placeholder.
+- **Format 4** — No existing API method — new API implementation needed. No Element/Selector lines.
+
+#### Background and Precondition Steps
+
+When test cases include `Background` or precondition (`Given`) steps, categorize each step before transforming.
+
+The reason for this categorization: Background steps set up the state needed for the test, but not all setup steps are equally important to include. CRUD actions (creating a user, setting up data) change system state and must always be designed — otherwise the test will fail. Data verifications in preconditions ("ensure the user exists") are only worth including if you already have a function that can do the check; building a new verification just for a precondition adds complexity with little value, since the CRUD step itself guarantees the state.
+
+| Step Type | Existing Function Found? | Action |
+|-----------|--------------------------|--------|
+| CRUD action (create, read, update, delete) | Yes | Include — use the found function (Format 1 or 2) |
+| CRUD action (create, read, update, delete) | No | Include — mark as new implementation needed (Format 3 for UI, Format 4 for API) |
+| Data verification / assertion | Yes | Include — use the found function (Format 1 or 2) |
+| Data verification / assertion | No | **Skip** — omit from the design |
+
+#### Consolidating Gherkin Steps
+
+Multiple consecutive Gherkin `And` steps that target the same UI element or form should be evaluated together:
+- If a single existing method handles the combined action (e.g., a `fillLoginForm(user, pass)` method covers both "enter username" and "enter password"), consolidate into one design step using Format 1.
+- Otherwise, keep them as separate design steps — each `And` step becomes its own numbered step.
+
+#### Handling Cleanup Steps
+
+Scenarios tagged with `@cleanup` require teardown steps at the end. Transform cleanup steps the same way as regular steps (using the format selection guide), and add them as the final numbered steps for that test case. Label these clearly so the implementer knows they run after the main test flow.
+
+#### Carrying Test Data Forward
+
+The upstream test-cases.md encloses variable data in double quotes (e.g., `"admin@example.com"`, `"2025-01-15"`, `"$500.00"`). Preserve these quoted values in your design steps — they appear as parameters in action calls (e.g., `LoginPage.fillEmail("admin@example.com")`) and make the test data explicit and traceable.
+
+#### Verification Steps
+
+`Then` / assertion steps in the Gherkin map to verification actions in the design. Search for existing assertion helpers (e.g., `expectVisible`, `expectText`, `expectCount`, `verifyTableRow`) before falling back to Format 3. Verification steps always need an Expected Result line that precisely states what should be true.
+
+### Step 4: Save
+
+Generate the ticket design document using the output structure from the template and save it:
+
+```
+.tickets/{TICKET_ID}/ticket-design.md
+```
+
+### Step 5: Summary
+
+Display the result to the user:
+
+```
+Ticket design created for ticket {TICKET_ID}.
+
+Created:
+- .tickets/{TICKET_ID}/ticket-design.md
+
+Summary:
+- Existing actions reused: {count}
+- Existing elements reused: {count}
+- New elements/actions needed: {count}
+
+Note: You need to update the missing selectors; you can use the FE source code or the MCP server.
+```
+
+Include the "Note" line when any steps use Format 3, so the user knows there are placeholders requiring attention.
+
+## Guiding Principles
+
+These principles explain the reasoning behind how the skill works — understanding them helps handle edge cases not explicitly covered above.
+
+- **Search thoroughly before defaulting to "new"** — the Format 3/4 placeholder is easy to write but expensive downstream. A few extra search queries now can save significant implementation effort. When in doubt, try one more search with variant naming patterns before concluding something doesn't exist.
+
+- **Complete all analysis before generating** — transforming steps one at a time without the full catalog leads to inconsistencies (e.g., using Format 3 for an element that a later search would have found). Finish Step 2 entirely before starting Step 3.
+
+- **Keep planning internal** — the catalog tables and search results are working artifacts. The user only needs the final ticket-design.md document and the summary.
+
+- **API actions are Element-free** — API calls operate at the service layer, not the UI. Attaching Element or Selector lines to an API action would confuse the implementer about where the code should live.
+
+- **Skip unverifiable preconditions** — converting a data verification precondition to Format 3 would force the implementer to build a verification helper just for setup, which adds complexity without improving test reliability. The CRUD action that creates the data already guarantees the state.
+
+- **File creation failure** — report the error and ask the user how to proceed.

package/kits/shared/skills/web-auto-ticket-design/templates/ticket-design.template.md

@@ -0,0 +1,138 @@
+# Ticket Design Template
+
+Use this template as the output structure for `ticket-design.md`.
+
+## Output Structure
+
+```markdown
+# Ticket Design
+
+## Ticket Information
+- Ticket ID: [ticket-id]
+- Feature: [main-feature - child-feature]
+- Related Feature: [related-feature or "None"]
+
+## [Test Case ID]: [Test Case Description]
+### Test Steps:
+[numbered test steps using formats 1, 2, 3, or 4]
+[if @cleanup: cleanup steps as final numbered steps]
+
+## [Next Test Case ID]: [Test Case Description]
+### Test Steps:
+[numbered test steps using formats 1, 2, 3, or 4]
+```
+
+**Notes on structure:**
+- Background/precondition steps appear first in the numbered sequence for each test case
+- Cleanup steps (from `@cleanup` tagged scenarios) appear last
+- Step numbering is sequential within each test case, starting at 1
+
+## Step Formats
+
+Choose the format based on what exists in the codebase.
+
+### Format 1 — Action method exists (API or UI action)
+
+Use for steps where a complete action method already exists. This includes API actions (e.g., CRUD helpers, data setup functions) and UI actions with a dedicated method. **Do not include Element or Selector lines** — the method encapsulates the full action.
+
+```
+[Step Number]. [Natural language description]
+  - Action: [Description] - [PageObject].[methodName]([parameters])
+  - Expected Result: [Expected outcome]
+```
+
+### Format 2 — Element exists but no specific action method
+
+Use for UI interactions where the element is defined but no dedicated action method exists. **Not applicable to API actions.**
+
+```
+[Step Number]. [Natural language description]
+  - Element: [Description of element]
+  - Action: [Action to perform] - [PageObject].[elementName]([parameters])
+  - Expected Result: [Expected outcome]
+```
+
+### Format 3 — Neither exists (new UI implementation needed)
+
+Use for UI interactions where neither the element nor the action exists. **Not applicable to API actions.**
+
+```
+[Step Number]. [Natural language description]
+  - Element: [Descriptive element name]
+  - Selector: <-- Update selector for this element -->
+  - Action: [Action to perform]
+  - Expected Result: [Expected outcome]
+  - Note: New element/action - needs to be implemented
+```
+
+### Format 4 — API action does not exist (new API implementation needed)
+
+Use for API actions (CRUD helpers, data setup/teardown, service calls) where no existing method is found. **Do not include Element or Selector lines.**
+
+```
+[Step Number]. [Natural language description]
+  - Action: [Action to perform]
+  - Expected Result: [Expected outcome]
+  - Note: New API action - needs to be implemented
+```
+
+## Example
+
+All four formats in a single test case, including background setup and cleanup:
+
+```markdown
+## TC042: Verify admin can create and delete a user
+### Test Steps:
+1. Create test organization via API
+  - Action: Create organization "Acme Corp" - OrganizationApi.create("Acme Corp")
+  - Expected Result: Organization is created successfully
+
+2. Navigate to the login page
+  - Action: Open login page - LoginPage.goto()
+  - Expected Result: Login page displays with username and password fields
+
+3. Enter valid credentials
+  - Element: Username input field
+  - Action: Enter username - LoginPage.usernameInput.fill("admin@example.com")
+  - Expected Result: Username appears in the input field
+
+4. Click login button
+  - Element: Login button
+  - Selector: <-- Update selector for this element -->
+  - Action: Click the login button
+  - Expected Result: User is redirected to the dashboard
+  - Note: New element/action - needs to be implemented
+
+5. Verify dashboard displays admin panel
+  - Element: Admin panel section
+  - Action: Check visibility - DashboardPage.adminPanel.isVisible()
+  - Expected Result: Admin panel is visible on the dashboard
+
+6. Delete test organization via API (Cleanup)
+  - Action: Delete organization "Acme Corp"
+  - Expected Result: Organization is deleted successfully
+  - Note: New API action - needs to be implemented
+```
+
+**What this example shows:**
+- Step 1: Format 1 — existing API action for background setup
+- Steps 2-3: Format 1 and 2 — existing UI actions
+- Step 4: Format 3 — new UI element needed
+- Step 5: Format 2 — existing element used for verification
+- Step 6: Format 4 — cleanup step (new API action needed)
+
+## Transformation Rules
+
+- Number all steps sequentially within each test case, starting at 1
+- Background/precondition steps come first in the sequence
+- Cleanup steps (from `@cleanup` tags) come last, with "(Cleanup)" appended to the description
+- Include both action and expected result for every step
+- Preserve quoted test data from Gherkin (e.g., `"admin@example.com"`, `"$500.00"`) as parameters in action calls
+- Include verification steps for all Gherkin `Then` statements — search for existing assertion helpers first
+- Use `Description - PageObject.methodName(parameters)` for function references
+- Include parameters for dynamic elements: `PageObject.elementName(parameters)`
+- When multiple Gherkin `And` steps are handled by a single method, consolidate into one design step
+- Mark new UI implementations with `Note: New element/action - needs to be implemented`
+- Mark new API implementations with `Note: New API action - needs to be implemented`
+- Use `<-- Update selector for this element -->` as the selector placeholder for Format 3
+- **API actions never include Element or Selector** — API calls (CRUD helpers, data setup/teardown, service calls) use Format 1 or Format 4 only