---
description: Convert Katalon True Platform/TestOps manual test cases, test suites, or requirement-linked cases into Playwright TypeScript automation. Use when you need to fetch/read Katalon Platform test cases and implement Playwright scripts, create or adapt a Playwright framework, apply Page Object Model and fixtures, or translate manual steps into meaningful automated test keywords.
alwaysApply: false
---

<!-- GENERATED by scripts/build-adapters.mjs from skills/. Do not edit by hand. -->

# Katalon Test Case To Playwright Script

Use this skill to turn Katalon Platform/TestOps test cases into maintainable Playwright TypeScript automation. Prefer existing project patterns when a Playwright framework already exists. Treat the human as a tool: ask concise questions whenever a required target, credential, repository, AUT detail, or test data value cannot be discovered safely.

## Workflow

```text
+-------------------+ --> +-------------------+ --> +---------------------+
| Resolve Katalon   |     | Read test cases   |     | Resolve framework   |
+-------------------+     +-------------------+     +---------------------+
                                                           |
                                                           v
+-------------------+ <-- +-------------------+ <-- +---------------------+
| Verify scripts    |     | Write automation  |     | Map manual steps    |
+-------------------+     +-------------------+     +---------------------+
```

## Katalon Source

Resolve the Katalon context before writing code:

- Use Katalon MCP tools when available to list projects, list repositories/Test Projects, find test suites, find test cases, and read each selected test case.
- If the user gives a test suite, read the suite and every included test case before generating scripts.
- If the user gives requirement keys, find requirement-linked cases first.
- If MCP tools are unavailable or authentication fails, ask the user for exported test cases, case URLs, case IDs, or the test case text.
- Preserve traceability by keeping Katalon case IDs or titles in test annotations, comments, tags, or test names according to the target framework's style.

Extract for each case:

- Title, priority, requirement links, folder/suite, preconditions, test data, manual steps, and expected results.
- AUT URL, user roles/accounts, environment, browser/device assumptions, and cleanup requirements.
- Ambiguous selectors or business data that require human input.

## Framework Resolution

Inspect the workspace before creating anything:

- Search with `rg --files` for `playwright.config.*`, `package.json`, `tests/`, `e2e/`, `fixtures/`, `pages/`, and existing `*.spec.ts` files.
- If a Playwright framework exists in the workspace, summarize the detected path, conventions, and intended files, then ask the user to confirm before modifying it.
- If multiple candidate frameworks exist, ask the user which one to use.
- If no Playwright framework exists, ask whether the user wants to provide a Git repository/path or wants the agent to create/copy a framework into a target directory.
- If the user does not provide a repository/path after that prompt and the current workspace is writable, initialize a Playwright TypeScript framework in the current workspace.

When initializing a new framework, use TypeScript and include:

- `playwright.config.ts`
- `tests/` for specs
- `pages/` for Page Object Model classes
- `fixtures/` for custom fixtures and shared test data
- meaningful helper methods that read like domain actions, not raw selector operations

Read `references/playwright-typescript.md` before scaffolding a new framework or making broad changes to an existing one.

## Automation Design

Translate manual Katalon steps into Playwright scripts using these rules:

- Use Page Object Model for page structure and domain actions.
- Use fixtures for authenticated users, test data, API setup, reusable pages, and environment URLs.
- Write spec names and test steps that remain understandable to a manual tester.
- Prefer stable user-facing locators: role, label, placeholder, text, test id. Avoid brittle CSS/XPath unless the app gives no better option.
- Convert manual expected results into assertions near the action that produces them.
- Keep one automated test aligned to one Katalon test case unless the existing framework groups scenarios differently.
- Do not silently invent credentials, URLs, product IDs, account state, or selectors. Ask the human or mark a small TODO only when the missing value cannot be discovered.

Use meaningful keywords in page objects and fixtures, for example:

```ts
await productCatalog.searchForPhone(testData.phoneName);
await productCatalog.expectPhoneVisible(testData.phoneName);
await cart.addVisibleProductToCart(testData.phoneName);
await checkout.expectOrderSummaryTotal(expectedTotal);
```

## Implementation Rules

- Follow the existing repository's naming, linting, folder, fixture, and assertion conventions when present.
- Keep generated code idiomatic TypeScript with explicit domain names and minimal comments.
- Store test data in the existing data fixture pattern; if none exists, create typed fixture data rather than scattering literals across specs.
- Add tags or annotations for Katalon case IDs when the framework supports it.
- Avoid changing unrelated framework config unless required for the requested tests.
- If the AUT must be inspected to identify selectors, use Browser/Playwright exploration and keep selectors stable.
- If live AUT access is blocked, implement the structure and mark only selector/test data gaps that require human input.

## Verification

After writing scripts:

- Run the narrowest available check: TypeScript compile, lint, Playwright list, or a targeted `npx playwright test`.
- If the test cannot run because credentials, AUT access, or dependencies are missing, report the exact blocker and what remains unverified.
- Report created/updated files, mapped Katalon cases, commands run, and any manual inputs still needed.

---

## Bundled references

_The reference material the skill points to is inlined below so this file is self-contained._


### references/playwright-typescript.md

# Playwright TypeScript Reference

## Framework Detection

Use these signals to detect an existing framework:

- `playwright.config.ts`, `playwright.config.js`, or `playwright.config.mts`
- `@playwright/test` in `package.json`
- spec files under `tests/`, `e2e/`, `specs/`, or feature folders
- existing `pages/`, `page-objects/`, `fixtures/`, `test-data/`, or `utils/`
- custom test exports such as `fixtures/base.ts`, `test.extend`, or `export const test`

When a framework exists, inspect a few representative specs, page objects, and fixtures before editing. Match imports, file naming, tag style, fixture names, and assertion style.

## New Framework Shape

For a new TypeScript framework, use a small structure:

```text
playwright.config.ts
tests/
  <feature>.spec.ts
pages/
  <page-name>.page.ts
fixtures/
  test.ts
  test-data.ts
```

Prefer `npm init playwright@latest` or the repository's package manager equivalent. Choose TypeScript, install browser dependencies only when needed, and avoid overwriting existing application files.

## Page Object Model

Page objects should expose business actions and assertions:

```ts
import { expect, type Locator, type Page } from '@playwright/test';

export class ProductCatalogPage {
  readonly page: Page;
  readonly searchInput: Locator;

  constructor(page: Page) {
    this.page = page;
    this.searchInput = page.getByRole('searchbox', { name: /search/i });
  }

  async goto(baseURL: string) {
    await this.page.goto(baseURL);
  }

  async searchForPhone(phoneName: string) {
    await this.searchInput.fill(phoneName);
    await this.page.getByRole('button', { name: /search/i }).click();
  }

  async expectPhoneVisible(phoneName: string) {
    await expect(this.page.getByText(phoneName, { exact: false })).toBeVisible();
  }
}
```

Avoid methods named only after low-level mechanics such as `clickButton` or `fillInput` unless they are private helpers. Use names that reflect the Katalon manual step's intent.

## Fixtures

Use fixtures to centralize reusable pages, users, and test data:

```ts
import { test as base } from '@playwright/test';
import { ProductCatalogPage } from '../pages/product-catalog.page';
import { testData } from './test-data';

type Fixtures = {
  productCatalog: ProductCatalogPage;
  data: typeof testData;
};

export const test = base.extend<Fixtures>({
  productCatalog: async ({ page }, use) => {
    await use(new ProductCatalogPage(page));
  },
  data: async ({}, use) => {
    await use(testData);
  },
});

export { expect } from '@playwright/test';
```

## Spec Mapping

Keep Katalon traceability visible:

```ts
import { test, expect } from '../fixtures/test';

test.describe('Search and filter', () => {
  test('TC-123 Verify phone price and stock search', async ({ productCatalog, data }, testInfo) => {
    testInfo.annotations.push({ type: 'katalonCaseId', description: 'TC-123' });

    await test.step('Open cellphone storefront', async () => {
      await productCatalog.goto(data.baseURL);
    });

    await test.step('Search for an in-stock phone', async () => {
      await productCatalog.searchForPhone(data.phones.inStock.name);
      await productCatalog.expectPhoneVisible(data.phones.inStock.name);
    });
  });
});
```

Each `test.step` should correspond to a meaningful manual action or assertion group, not every tiny Playwright call.

## Human-As-Tool Questions

Ask the human when any of these are missing and cannot be discovered:

- target repository or directory
- permission to modify an existing framework
- AUT URL or environment
- credentials, roles, or setup data
- unique product/order/user records
- selector strategy when the UI cannot be inspected
- whether to scaffold a new framework or use a provided repository

Keep questions short and actionable. Ask only for required values needed to continue.