true-platform-testing · git:20260807.153bbcd · 2026-08-07 · sha256 7fe7fb56ab777600

true-platform-testing git:20260807.153bbcdA

Immutable. This exact content is served forever at /api/v1/blob/7fe7fb56ab777600.

---
description: End-to-end Katalon True Platform testing workflow and lifecycle router. Use when one request spans several stages and no single skill owns all of it, for example analyze a requirement, design and import the cases, build a suite, run it with AI, and report the outcome. Also use to route any testing request across the full 7-stage lifecycle (plan, design, manage, review, execute, analyze, maintain) to the right focused skill, and for deciding what is and is not available through the Katalon MCP tools. Start here when a request names a job rather than one task, such as drive the whole chain from requirement to ship call. Also start here when the asker wants orienting before acting, for example where do I start, which skill do I need, or I own quality here and do not know where to begin. Routes the asker to the skill that owns their next step, whether they say manual tester, QA analyst, test analyst, automation tester, SDET, automation engineer, QA engineer, test lead, QA lead, test manager, or QA manager.
alwaysApply: false
---

# Katalon True Platform Testing

Use this skill for requirement-to-execution workflows in Katalon True Platform/TestOps, and as the **router across the full 7-stage testing lifecycle**. Prefer Katalon MCP tools for platform operations and Browser/Playwright only for external AUT exploration or visual verification.

## Role Routing

Ask who is in front of you before asking which stage they are in. A skill is listed here when a request phrased in role terms, naming no skill, should land there first. Everything else is reached by handoff.

| Role | Comes here to | Starts at | Then |
|---|---|---|---|
| Manual tester | turn a written requirement into cases and run them | `create-test-cases` | `execute-test`, `analyze-failures` |
| Automation tester | turn cases into code, run it, ship the results | `test-case-to-playwright` | `playwright-execute`, `upload-report`, `test-maintenance` |
| Test lead | scope the cycle, judge readiness, keep the suite healthy | `test-plan` | `test-review`, `test-management`, `release-analyze` |
| Test manager | read coverage and risk, and call ship | `release-analyze` | `test-review`, `test-management` |

`platform-setup` is role-neutral and comes first for everyone who has not connected the MCP yet. Synonyms (SDET, automation engineer, QA engineer, QA analyst, test analyst, QA lead, QA manager), the full intent-to-skill map, and what to fall back to for the parts not built yet are in `references/lifecycle-map.md`.

## Lifecycle Routing

The Katalon testing lifecycle has 7 stages. For a focused request, route to the matching skill; for a full-flow request, run the stages in order and stop when the user's goal is met. Full map + tool lists: `references/lifecycle-map.md`.

| Stage | Route to skill | When |
|---|---|---|
| 1 Plan | `test-plan` | scope, risk-prioritized plan, executable folder+suite for a sprint/release |
| 2 Design | `create-test-cases` (+ `test-case-to-playwright`) | author/import cases from requirements |
| 3 Manage | `test-management` | organize inventory, classify, requirement traceability audit |
| 4 Review | `test-review` | pre-pipeline coverage/quality/flakiness verdict |
| 5 Execute | `execute-test` (+ `upload-report`, `playwright-execute`) | manual, Run with AI, automated, cloud |
| 6 Analyze | `analyze-failures` + `release-analyze` | failure triage/defects; ship/no-ship call |
| 7 Maintain | `test-maintenance` | repair flaky/broken cases, regenerate, feed gaps back to plan |
| pre / cross | `platform-setup` | connect and verify the MCP |

For multi-skill plays (requirement-to-ship, coverage rescue, flaky cleanup, manual-to-automation, cross-lane trust check, traceability audit) read `references/combination-recipes.md`. For copy-paste prompts and cross-model/cross-agent execution notes read `references/prompt-recipes.md`. For the full MCP tool list read `references/mcp-tool-index.md`.

This skill can run any stage inline itself (the workflows below cover requirement->execution->report); route to a focused skill when the user wants only that stage or a deeper treatment (traceability, review verdict, failure triage, maintenance).

## Autonomy Policy

When the user asks for an end-to-end Katalon flow, try to complete the full available workflow without pausing for optional decisions:

Default assumptions:

- If exactly one Katalon project or repository matches the user's wording or current context, use it.
- If exactly one repository exists, use it.
- If no AUT environments exist and the user supplied or requirement contains a URL, use that URL as `default_aut_environment_url` for AI execution.
- If AUT environments exist, choose the environment whose URL/name best matches the target AUT. Ask only if no match is clear.
- After creating any manual test execution, start Run with AI automatically and wait for completion unless the user explicitly says not to run AI.
- If a matching test case already exists, reuse and update/link it instead of creating a duplicate.
- If a matching test suite already exists, reuse it and add missing cases instead of creating a duplicate.

Ask the user only when a required value cannot be resolved safely, multiple equally valid choices remain, credentials/accounts are missing, the next action is destructive, or the user explicitly asks for approval gates.

## Availability First

Before promising a workflow, state the automation boundary:

- Available through Katalon MCP: list projects/repositories, find/read requirements, create/read/update test cases, link requirements, find/manage test suites and folders, create manual test runs, start Run with AI, poll AI sessions, read execution/test results, fetch quality metrics, and create ALM-linked defects.
- Not directly available through Katalon MCP: create requirements, create a formal Test Plan entity, guarantee AI execution completion, or inspect the live AUT UI without Browser/Playwright.
- Workaround for test plans: use a named test suite or folder plus release/sprint association as the executable test plan structure.

For details, read `references/unavailable-capabilities.md` when the user asks "can Katalon do X?" or when planning scope.

## Required Context Workflow

Always resolve context in this order before mutating Katalon data:

Rules:

- Treat repository and Test Project as the same resolution target.
- If the user says "Katalon Cloud" or "cloud repo", prefer a repository named `Katalon Cloud` when present.
- Do not scan all repositories to avoid choosing. Resolve from context or ask when ambiguous.
- For full-flow requests, perform non-destructive writes without asking again once project/repository/requirement scope is resolved.
- Before destructive writes or bulk changes outside the requested flow, summarize the intended changes and get approval.

## Requirement Analysis

Use `find_requirements` or `read_requirement` when requirements exist in Jira/Azure integration. If requirements are provided in chat, analyze them locally and only use Katalon to create/link test assets.

Output requirement analysis as:

- Requirement intent
- User roles/personas
- Main flows
- Alternate and negative flows
- Data and environment assumptions
- Risk areas
- Coverage recommendations

Read `references/requirement-analysis.md` for the checklist.

## Manual Test Case Design

Write manual test cases in a platform-importable style:

- Title: concise and action-oriented.
- Description: what behavior is verified.
- Pre-condition: environment, data, account, AUT state.
- Steps: manual tester phrasing, each starting with a concrete action.
- Expected results: observable UI/API/platform result per step.
- Test data: values, URLs, accounts, or `N/A`.
- Priority: P0/P1/P2 when useful.
- Requirement links: source keys or internal requirement IDs when available.

Mirror the style of related existing test cases before drafting new or updated cases:

- Read representative existing cases for the same requirement, feature area, folder, suite, product flow, or repository.
- Use their naming convention, field structure, step granularity, vocabulary, pre-condition style, test data style, and expected-result detail level.
- Keep new coverage consistent with the local suite unless the existing style is clearly incomplete or obsolete.
- If existing cases are weak, preserve platform compatibility while improving only what is needed for correctness and coverage.
- When no related cases exist, use the default manual test case format below.

Design enough coverage using ISTQB test design techniques as a reference before importing cases (the techniques guide the design; the output is plain platform test cases, not an ISTQB certification):

- Use equivalence partitioning for input classes, filters, statuses, user roles, and product states.
- Use boundary value analysis for numeric ranges, quantities, prices, dates, pagination, and length limits.
- Use decision table testing for business rules with combinations of conditions.
- Use state transition testing for workflows such as cart, checkout, execution status, and lifecycle changes.
- Use use-case/scenario testing for end-to-end user journeys.
- Use error guessing/checklist-based testing for common ecommerce/platform risks.
- Use pairwise or combinatorial reduction when variants explode, while preserving high-risk combinations.

Keep each case **atomic in scope** (one validation condition per case) so a failure pinpoints the exact rule and each requirement line maps 1:1 to a result. Atomic is about scope, not step count: every case is still a complete, runnable flow (precondition/navigation -> enter surrounding valid data -> action under test -> verify), never a lone bare assertion. Cover the happy-path flow and its edge cases (boundary + negative variants), not just the positive path. Reserve combined cases for true end-to-end scenarios. Quote expected error/UI strings verbatim from the requirement, including source typos (flag them separately). If coverage is intentionally reduced, state the risk-based rationale.

Read `references/istqb-coverage.md` before designing cases from requirements. Read `references/manual-test-case-format.md` before creating many cases or when the user asks for a specific format.

## Existing Test Case Check

Before creating or importing any test case, check whether suitable coverage already exists:

- If requirement IDs are known, call `find_test_cases_by_requirement` first.
- Search by requirement key, title keywords, feature area, and target folder with `find_test_cases`.
- Read likely matches with `read_test_case` when title alone is not enough to judge coverage.
- Read enough related cases to infer the local writing style before drafting new cases, even when the related cases do not fully cover the requested behavior.
- Reuse, update, move, or link existing cases when they already cover the behavior.
- Create new cases only for uncovered behavior, missing coverage classes, or clearly obsolete/incorrect existing coverage.
- Report what was reused, what was updated, and what was newly created.

This check is mandatory for write/import/full-flow requests, including retries after partial failure. Do not create duplicate cases simply because a previous create attempt failed. If no related cases can be found, say that the new cases follow the default skill format.

## Import And Traceability Workflow

Use this flow for "write test cases and import to platform":

```text
+----------------------+ +-----------------------+ +----------------------+
| Analyze requirements | --> | Draft coverage design | --> | Find existing cases |
+----------------------+ +-----------------------+ +----------------------+
| | |
v v v
+----------------------+ +-----------------------+ +----------------------+
| create/update needed | --> | link_requirements | --> | read_test_case verify|
+----------------------+ +-----------------------+ +----------------------+
```

Tool rules:

- Search for existing matching test cases before every create/import action.
- Use `create_test_case` only for manual test cases that do not already have suitable coverage.
- Use `link_requirements_to_test_case` only after requirement IDs are known.
- Use `read_test_case` after creation when verification matters.
- Use `update_test_case` for revisions; pass all intended updates in one call.
- Use `manage_test_folder` or `move_test_case` for organization when requested.

## Test Suite And "Test Plan" Workflow

When the user says "search and design test plan":

1. Use `find_test_cases`, `find_requirements`, and `find_iterations` as needed to understand scope.
2. Propose a test plan structure in chat: objectives, in-scope/out-of-scope, coverage matrix, risks, environments, suites.
3. Implement the executable structure with `manage_test_suite` and optional folders.
4. Add selected test cases to suites.
5. Verify with `read_test_suite`.

For formal Test Plan entity creation, state that the current MCP does not expose a direct create-test-plan tool.

## Manual Execution And Run With AI

Use this flow for manual execution:

```text
+------------------+ +----------------------+ +-----------------------+
| read_auts | --> | create_manual_run | --> | read_test_suite |
+------------------+ +----------------------+ +-----------------------+
| | |
v v v
+------------------+ +----------------------+ +-----------------------+
| create_ai_session| --> | read_ai_session poll | --> | report results |
+------------------+ +----------------------+ +-----------------------+
```

Rules:

- If the user asks for the full flow, test cases just created, or Run with AI, treat the execution as manual unless they explicitly ask for automated execution.
- If the user asks only to "run tests" and no test type can be inferred, ask: "Do you want to run manually or automated?"
- For manual execution, always call `read_auts` immediately before `create_manual_test_run`.
- Choose the best matching AUT/environment automatically when URL/name clearly matches the target AUT. Ask only when multiple AUTs are equally plausible.
- Never reuse AUT environment selection from an earlier turn or earlier run.
- After any manual test execution is created, start Run with AI automatically unless the user explicitly says not to. Do not ask whether to continue with AI.
- Before `create_manual_ai_session`, call `read_test_suite` for every suite from the manual run and pass non-empty test case lists.
- Poll `read_manual_ai_session` until all items are no longer TODO/IN_TESTING. If the session stays queued or running for a long time, keep polling at practical intervals and report an in-progress state only when the user asks for status or an external platform timeout/error is observed.

Read `references/execution-workflow.md` before creating executions.

## Automated Execution

Use automated execution only for automated test suites:

```text
+------------------+ --> +--------------------+ --> +----------------------+
| find_test_suites | | build run config | | schedule_test_run |
+------------------+ +--------------------+ +----------------------+
```

Rules:

- Use `schedule_test_run`, never `create_manual_test_run`, for automated suites.
- Do not run individual manual test cases through `schedule_test_run`.
- Use `find_execution_profiles`, `list_test_cloud_environments`, `build_run_configuration`, and optionally `build_schedule`.
- For mobile runs, ask whether the target is mobile browser or mobile app when app details are missing.

## Result Review And Response

After execution, read results before responding:

- Manual AI run: `read_manual_ai_session`, then relevant execution/result tools if IDs are available.
- TestOps execution: `read_execution`, `read_execution_test_results`, `read_test_result`.
- Recent or specific results: `find_test_results`.
- Quality summaries: `fetch_requirement_data`, `fetch_test_case_data`, `fetch_defect_data`, `fetch_test_configuration_data`, `fetch_test_stability_data`.

Report in chat with:

- Execution/run link when returned by the platform.
- Pass/fail/blocked counts.
- Failed cases and concise failure reason.
- Defects created or recommended.
- Gaps, skipped items, and what needs manual follow-up.

## Defects

Use `create_defect` only when a failed test result ID is known. First call `find_alm_integration_projects` if ALM integration IDs are unknown. Ask the user before creating defects unless they explicitly requested defect creation for failures.

---

## Bundled references

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

### references/combination-recipes.md

# Combination recipes — multi-skill, multi-tool playbooks

Each recipe chains several skills and MCP tools into one end-to-end play. Trigger phrase, skill order, key tools, stop condition, boundary.

## R1 — Requirement to ship call (stages 1->6)
- **Trigger:** "test CEL-6 end to end and tell me if we can ship."
- **Skills:** `test-plan` -> `create-test-cases` -> `execute-test` -> `analyze-failures` -> `release-analyze`.
- **Tools:** `fetch_requirement_data`, `find_test_cases_by_requirement`, `create_test_case`, `link_requirements_to_test_case`, `manage_test_suite`, `read_auts`, `create_manual_test_run`, `create_manual_ai_session`, `read_manual_ai_session`, `read_test_result`, then the `fetch_*` quality tools.
- **Stop when:** release verdict issued (Ready / Ready with risk / Not ready).
- **Boundary:** no release-gate authoring; the ship call reads gates, it does not set them.

## R2 — Coverage rescue (stages 3->4->2)
- **Trigger:** "we have gaps, fix our coverage for project X."
- **Skills:** `test-management` (find orphan requirements/cases) -> `test-review` (verdict on what exists) -> `create-test-cases` (fill).
- **Tools:** `find_test_cases_by_requirement`, `fetch_requirement_data`, `find_test_cases`, `fetch_test_case_data`, then `create_test_case` + `link_requirements_to_test_case`.
- **Stop when:** every in-scope requirement has >=1 linked case and the review verdict is Approve / Approve-with-fixes.

## R3 — Flaky-suite cleanup (stages 6->7->4)
- **Trigger:** "our regression is flaky, clean it up."
- **Skills:** `analyze-failures` (classify automation defects) -> `test-maintenance` (repair/regenerate) -> `test-review` (re-approve).
- **Tools:** `find_test_results`, `read_test_result`, `fetch_test_stability_data`, `update_test_case`, `move_test_case`, then re-run + `fetch_test_stability_data` again.
- **Stop when:** flaky cases in the critical path are repaired or retired and the suite re-approves.

## R4 — Manual to automation graduation (stages 2->5)
- **Trigger:** "turn these manual cases into automation and run them into the platform."
- **Skills:** `create-test-cases` -> `test-case-to-playwright` -> `playwright-execute` -> `upload-report`.
- **Tools:** `read_test_case`, `find_test_cases`, then Playwright codegen + `@katalon/playwright-reporter` upload, verified via `read_execution` / `find_test_results`.
- **Stop when:** the Playwright run is uploaded and the platform run is verified.

## R5 — Cross-lane trust check (stages 5->6)
- **Trigger:** "don't trust the AI pass, verify it against real automation."
- **Skills:** `execute-test` (manual Run with AI) + `playwright-execute` (code lane) -> `analyze-failures`.
- **Tools:** `create_manual_ai_session`, `read_manual_ai_session`, Playwright run + `@katalon/playwright-reporter` upload, then `read_test_result` on both.
- **Stop when:** every critical case's manual AI verdict is confirmed against the code-lane ground truth; discrepancies recorded.
- **Boundary:** a self-reported AI PASS contradicted by the code lane is not a PASS.

## R6 — Traceability audit (stage 3)
- **Trigger:** "show me requirement-to-test coverage."
- **Skills:** `test-management`.
- **Tools:** `find_requirements`, `find_test_cases_by_requirement`, `fetch_requirement_data`, `find_test_cases`.
- **Stop when:** the requirement <-> case <-> suite matrix + orphan lists + coverage % are reported.

## Composition rule

Always resolve project/repository once at the start, reuse that scope across the whole recipe, and state the boundary before promising any step. Ask only when a required value cannot be resolved safely.

### references/execution-workflow.md

# Execution Workflow

## Manual Run With AI

1. Resolve project and repository.
2. Search existing coverage first, then resolve existing test cases or create only missing cases.
3. Add cases to a manual test suite if grouping is needed.
4. Call `read_auts`.
5. Choose the matching AUT/environment automatically when one clearly matches the target AUT. If none exist and a URL is known, use it as `default_aut_environment_url` for AI execution.
6. Call `create_manual_test_run`.
7. Continue to AI automatically after creating any manual execution unless the user explicitly says not to run AI.
8. Call `create_manual_ai_session`.
9. Poll with `read_manual_ai_session` until every test case leaves TODO/IN_TESTING.
10. Summarize result in chat.

## Manual Run Rules

- Never call `create_manual_test_run` without a fresh `read_auts` first.
- Never reuse AUT environment choices from earlier turns.
- Start Run with AI without asking again after any manual run is created.
- Do not ask whether to continue with AI unless the user explicitly requests a manual run without AI.
- If the manual run contains newly created test cases, they are manual by default.
- Render returned execution paths as markdown links.
- Wait for AI completion before final response. If the platform stays pending/running for an unusually long time, keep polling at practical intervals and only report in-progress status when the user asks or the platform returns a timeout/error.
- Ask for user input only when required data is missing, multiple AUTs are equally plausible, the user explicitly disables AI, or the next action is destructive.

## Automated Run

1. Resolve repository.
2. Find automated test suites or suite collections.
3. Find execution profiles.
4. Select TestCloud environments.
5. Build run configuration.
6. Optionally build schedule.
7. Call `schedule_test_run`.
8. Read execution and results.

## Automated Run Rules

- Use `schedule_test_run` only for automated suites.
- Do not run manual test cases through automated scheduling.
- For mobile native, ensure app details are present.
- For mobile availability filters, clarify automation/manual vs live testing when needed.

## Result Reporting Template

```text
Run:
- Name:
- Link:
- Status:

Summary:
- Passed:
- Failed:
- Blocked/Incomplete:
- Not run:

Findings:
- ...

Next actions:
- ...
```

### references/istqb-coverage.md

# Coverage Guide (ISTQB techniques as reference)

Use this guide before writing or importing test cases. ISTQB is the **reference toolkit** for designing coverage here, not the deliverable: the output is plain platform test cases designed *using* these techniques, not "ISTQB cases" certified against the standard. The goal is enough risk-based coverage, not maximum case count.

## Technique Selection

- Equivalence Partitioning: use for valid/invalid classes such as product categories, brands, stock states, payment methods, account roles, and form input classes.
- Boundary Value Analysis: use for numeric or ordered values such as price range, quantity, pagination, character limits, dates, and timeout thresholds.
- Decision Table Testing: use when outcomes depend on combinations of conditions, such as selected variant + stock + quantity, checkout field validity, shipping eligibility, or payment availability.
- State Transition Testing: use when behavior depends on prior state, such as empty cart -> item added -> quantity updated -> removed, checkout step progression, or execution TODO -> IN_TESTING -> PASSED/FAILED.
- Use Case / Scenario Testing: use for end-to-end journeys that represent user goals, such as browse -> select variant -> add to cart -> checkout.
- Error Guessing / Checklist-Based Testing: use for likely failures based on domain knowledge, such as broken images, stale cart totals, invalid email, unavailable product, duplicate submission, or navigation loss.
- Pairwise / Combinatorial Testing: use when many variables interact, such as browser x device x category x filter x sort, while preserving explicitly high-risk combinations.

## Minimum Coverage Expectations

For each requirement, identify:

- At least one happy-path scenario.
- At least one negative or validation scenario when user input or branching exists.
- Boundary cases for numeric/date/range fields.
- State transitions for multi-step workflows.
- Role/permission coverage when roles exist.
- Data setup and cleanup assumptions.
- Requirement-to-test traceability.

## Coverage Output Format

Before importing tests, prepare a short coverage note:

```text
Coverage Techniques:
- Use case testing: ...
- Equivalence partitions: ...
- Boundary values: ...
- Decision table/state transition: ...
- Error guessing risks: ...

Selected Test Cases:
- P0: ...
- P1: ...
- P2: ...

Deferred / Not Covered:
- ...
Reason:
- ...
```

## Case Granularity

- Keep each case **atomic in scope**: one validation condition / one acceptance-criteria line per case, so a failure pinpoints the exact rule and each requirement line maps 1:1 to a result.
- Atomic does not mean a single step. Every case is a **complete, runnable flow**: precondition/navigation -> enter surrounding valid data -> perform the action under test -> verify the result. Avoid lone-step cases like "count the columns"; include the steps to reach and exercise that state so the case executes on its own (including under Run with AI).
- Cover the happy-path flow **and** its edge cases for every feature: main success flow plus boundary and negative variants. Do not stop at the positive path.
- Quote expected error/UI strings verbatim from the requirement, including source typos; flag suspected typos separately rather than correcting them in the expected result.

## Practical Rules

- Do not create redundant tests that exercise the same partition and same expected behavior.
- Prefer fewer strong tests over many shallow tests.
- Mark P0 for revenue, checkout, account, data-loss, or broken-entry-point risks.
- Mark P1 for important catalog, filter, sort, and traceability behaviors.
- Mark P2 for cosmetic, footer, secondary navigation, or low-risk edge cases.
- If a test is primarily exploratory or visual, say so and include what evidence is needed.

### references/lifecycle-map.md

# Lifecycle map — 7 stages -> skills -> MCP tools

Single source for the README diagram and the orchestrator's routing. The Katalon testing lifecycle has 7 stages; each maps to one or more skills and a set of MCP tools.

```text
1 PLAN ......... test-plan
list_projects, list_repositories, find_iterations,
fetch_requirement_data, find_test_cases_by_requirement,
manage_test_folder, manage_test_suite

2 DESIGN ....... create-test-cases (+ test-case-to-playwright)
find_requirements, read_requirement, create_test_case,
read_test_case, update_test_case, find_test_cases

3 MANAGE ....... test-management
find_test_folders, manage_test_folder, find_test_suites,
manage_test_suite, move_test_case, duplicate_test_case,
link_requirements_to_test_case, unlink_requirements_from_test_case,
find_test_cases_by_requirement, fetch_requirement_data

4 REVIEW ....... test-review
fetch_requirement_data, fetch_test_case_data,
fetch_test_stability_data, fetch_test_configuration_data,
find_test_cases_by_requirement, read_auts

5 EXECUTE ...... execute-test (+ upload-report, playwright-execute)
read_auts, create_manual_test_run, create_manual_ai_session,
read_manual_ai_session, find_execution_profiles,
list_test_cloud_environments, build_run_configuration,
build_schedule, schedule_test_run, read_execution,
read_execution_test_results

6 ANALYZE ...... analyze-failures + release-analyze
read_test_result, read_execution_test_results, find_test_results,
fetch_defect_data, fetch_test_case_data, fetch_test_stability_data,
fetch_test_configuration_data, fetch_requirement_data,
find_alm_integration_projects, create_defect

7 MAINTAIN ..... test-maintenance
fetch_test_stability_data, find_test_results, read_execution,
update_test_case, move_test_case, duplicate_test_case
|
+--> feeds the gap list back to 1 PLAN (the loop closes)

CROSS-CUTTING .. platform-setup (connect) · true-platform-testing (router)
```

## Stage boundaries (no MCP)

- Object/action capture, data design, resilience design (stage 2): Studio desktop.
- Custom fields/tags, Git config, governance (stage 3): TestOps UI.
- Code/object review, local debug (stage 4): Studio desktop.
- Rerun / terminate / Live Monitor (stage 5): TestOps UI (MCP reads results only).
- AI root-cause, self-healing, Time Capsule, TrueTest regeneration (stages 6-7): product surfaces, not MCP.

Use Browser/Playwright for AUT exploration; use Studio for object/script work; use the MCP for everything in the tool lists above.

## Role map

Four canonical roles. The synonyms are prose only, so someone who uses the industry's noun instead of Katalon's still finds their row.

| Role | Also called | Comes here to | Starts at | Then |
|---|---|---|---|---|
| Manual tester | QA analyst, test analyst, QA engineer | turn a written requirement into cases and run them | `create-test-cases` | `execute-test`, `analyze-failures` |
| Automation tester | SDET, automation engineer, QA engineer | turn cases into code, run it, ship the results | `test-case-to-playwright` | `playwright-execute`, `upload-report`, `test-maintenance` |
| Test lead | QA lead, QE lead, test coordinator | scope the cycle, judge readiness, keep the suite healthy | `test-plan` | `test-review`, `test-management`, `release-analyze` |
| Test manager | QA manager, QE manager, head of quality | read coverage and risk, and call ship | `release-analyze` | `test-review`, `test-management` |

A skill is named here when a request phrased in role terms, naming no skill, should land there first. Everything else is reached by handoff. `QA engineer` maps to two roles on purpose: resolve it by asking one question, never by guessing.

`platform-setup` is role-neutral. It routes on the words connect, install, and MCP rather than on a role, and everyone runs it once.

## Intent to skill

**When a row's owning skill does not exist yet, route to the fallback and say the boundary out loud. Never invent a capability to fill a row.**

| Intent, in the tester's words | Route to today | When the gap closes |
|---|---|---|
| Where do I start, I own quality for this and do not know the tooling | `true-platform-testing` | covered |
| Connect the platform, nothing works | `platform-setup` | covered |
| Analyze this requirement before I write anything | `create-test-cases` | covered |
| I just got requirement CEL-6 and need cases | `create-test-cases` | covered |
| What test data do these cases need | `create-test-cases`, per-case test data field only | `test-data` |
| Seed and tear down data for the run | **boundary only.** No skill owns this. State it | `test-data` |
| Run an exploratory session on checkout | `create-test-cases`, scenario and error-guessing techniques | exploratory charter skill, not yet named |
| What should we test first this sprint | `test-plan` | covered |
| How many testers, how long, for this release | `test-plan`, scope only. State the boundary | `test-estimation` |
| Which product areas carry the most risk this quarter | `test-plan`, per-cycle risk ranking only. State the boundary | `risk-portfolio` |
| Organize our test cases, they are a mess | `test-management` | covered |
| Which requirements have no coverage | `test-management` | covered |
| Is this suite good enough for the pipeline | `test-review` | covered |
| Run these cases and tell me what broke | `execute-test` | covered |
| Run it with AI, I do not have time to click through | `execute-test` | covered |
| Schedule the automated suite on TestCloud | `execute-test` | covered |
| Turn TC-1042 into a Playwright spec | `test-case-to-playwright` | covered |
| Get my Playwright run into the platform | `playwright-execute` | covered |
| I have a JUnit or Katalon report on disk | `upload-report` | covered |
| Turn this manual case into a Cypress spec | `test-case-to-playwright` as the pattern, `upload-report` via a Mocha JUnit reporter. State the boundary | Cypress pair |
| Turn this manual case into a Selenium test | `upload-report`, JUnit XML path only. State the boundary | Selenium pair |
| Turn this manual case into a Katalon Studio test | `upload-report` runs `katalonc`, execution only, no authoring. State the boundary | Katalon Studio pair |
| Wire this into CI | `playwright-execute` + `upload-report`, both expose CI-invocable commands | `ci-setup` |
| This run failed, is it us or the app | `analyze-failures` | covered |
| File the bugs for these failures | `analyze-failures` | covered |
| Our Cypress suite is flaky | `test-maintenance` | Cypress pair, for the framework-specific rerun path |
| Which tests went flaky this month | `test-maintenance` | covered |
| Can we ship 3.2 | `release-analyze` | covered |
| I need a status deck for the steering committee | `release-analyze`, single-release verdict only. State the boundary | `test-reporting` |
| Trend escaped defects across the last four releases | `release-analyze`, single release only. State the boundary | `test-reporting` |
| What should we change about how we test | `test-maintenance`, asset-level gap list only. State the boundary | `test-retro` |
| Assert on an email, a PDF, a visual, a credential, or a database row inside a test | **boundary only.** No skill owns this. State it | not yet named, script distribution still blocks it |

### references/manual-test-case-format.md

# Manual Test Case Format

Use this format when generating cases for Katalon True Platform.

## Fields

- Name: short verb-led title.
- Description: one or two sentences explaining the behavior under test.
- Pre-condition: environment, account, seed data, cart state, login state, AUT URL, and any browser/device assumptions.
- Test Steps: manual style actions. Start with navigation when page context matters.
- Expected Results: observable outcome for each step.
- Test Data: concrete values used by the step, or `N/A`.
- Priority: P0 critical path, P1 important functional path, P2 secondary/edge path.
- Requirement IDs: internal requirement IDs or source keys when linking is requested.

## Step Quality Rules

- Write one user action per step.
- Use visible labels and URLs, not implementation selectors.
- Put validations in Expected Results, not the action.
- Avoid "verify everything looks correct"; specify what must be visible or changed.
- Split long end-to-end flows when setup makes individual failures hard to diagnose.

## Katalon Import Notes

- Before creating test cases, search existing coverage with `find_test_cases_by_requirement` when requirement IDs are known and `find_test_cases` by title, requirement key, feature area, and folder.
- Reuse or update matching existing cases instead of creating duplicates.
- Create manual test cases with `create_test_case`.
- Link requirements after creation with `link_requirements_to_test_case`.
- Verify important created cases with `read_test_case`.
- Revise existing cases with one `update_test_case` call containing all updates.

## Example Shape

```text
Name: Add selected product variant to cart
Description: Verify that a shopper can select a product variant and add the selected quantity to cart.
Pre-condition: Storefront is available. Cart is empty.

### references/mcp-tool-index.md

# MCP tool index — every Katalon MCP tool, one line, stage-tagged

Stages: 1 plan · 2 design · 3 manage · 4 review · 5 execute · 6 analyze · 7 maintain.

## Discovery
- `list_projects` — list Katalon projects. [1,2,3,5]
- `list_repositories` — list repositories / Test Projects. [1,3]
- `find_iterations` — find sprints/iterations for a project. [1]

## Requirements
- `find_requirements` — find synced requirements (Jira/Azure). [2]
- `read_requirement` — read one requirement's detail. [2]
- `fetch_requirement_data` — requirement coverage status. [1,4,6]

## Test cases
- `create_test_case` — create a manual test case. [2]
- `read_test_case` — read a test case. [2,4]
- `update_test_case` — update a case (all edits in one call). [2,7]
- `duplicate_test_case` — copy a case. [7]
- `delete_test_case` — delete a case (unreliable; prefer update/move). [3]
- `move_test_case` — move a case between folders. [3,7]
- `find_test_cases` — search cases by key/title/feature/folder. [2,3]

## Folders and suites
- `find_test_folders` — list folders. [3]
- `manage_test_folder` — create/organize folders. [1,3]
- `find_test_suites` — list suites. [3,5]
- `read_test_suite` — read a suite's cases. [3,5]
- `manage_test_suite` — create/edit a suite. [1,3]

## Requirement links
- `link_requirements_to_test_case` — link req -> case. [3]
- `unlink_requirements_from_test_case` — remove a link. [3]
- `find_test_cases_by_requirement` — cases linked to a requirement. [1,3,4]

## Manual execution
- `read_auts` — read applications-under-test / environments (call right before a manual run). [4,5]
- `create_manual_test_run` — start a manual run. [5]
- `create_manual_ai_session` — start Run with AI. [5]
- `read_manual_ai_session` — poll AI session until no item is TODO/IN_TESTING. [5]

## Automated execution
- `find_execution_profiles` — execution profiles. [5]
- `list_test_cloud_environments` — TestCloud environments. [5]
- `build_run_configuration` — build a run config. [1,5]
- `build_schedule` — build a schedule. [5]
- `schedule_test_run` — schedule an automated run (never for manual cases). [1,5]

## Results
- `read_execution` — read an execution. [5,6,7]
- `read_execution_test_results` — results within an execution. [5,6]
- `read_test_result` — one test result's detail (needed for defect filing). [6,7]
- `find_test_results` — find recent/specific results. [6,7]

## Quality data
- `fetch_defect_data` — defect status/context. [6,7]
- `fetch_test_case_data` — test-case quality signals. [4,6]
- `fetch_test_stability_data` — flakiness/stability signal. [4,6,7]
- `fetch_test_configuration_data` — configuration coverage. [4,6]

## ALM defects
- `find_alm_integration_projects` — ALM integration projects. [6]
- `create_defect` — create an ALM-linked defect (requires a failed result ID). [6]

## Not available via MCP (state as boundary)
Create requirements · create Release/Build/Test-Plan entity · author release gates · guarantee Run-with-AI completion · inspect AUT UI · self-healing / Time Capsule / Tracer / object refactor · TrueTest regeneration · rerun/terminate/Live-Monitor · custom fields & tags · Git repo config · project governance. Use Jira/Azure, Studio, TestOps UI, or Browser/Playwright for these.

### references/prompt-recipes.md

# Prompt recipes + cross-model / cross-agent execution notes

These skills are agent-neutral and must run on any coding agent (Claude, ChatGPT/Codex, Gemini, Copilot, Cursor, Kiro, Windsurf, Cline, Continue) and any model tier (Opus down to Haiku/small). Smaller models reason less, so the skills are written to be **followed, not interpreted**.

## Cross-model design principles (why the skills read the way they do)

1. **Deterministic tool order.** Steps are numbered and the tool sequence is fixed. A small model should never have to decide *which* tool — only execute the next numbered call.
2. **Explicit stop conditions.** Every loop states when to stop (e.g. "poll `read_manual_ai_session` until no item is TODO/IN_TESTING, then stop"). No open-ended "keep checking".
3. **One decision at a time.** Resolve project -> repository -> requirement in that fixed order. Ask only when a value cannot be resolved safely.
4. **Boundary stated up front.** Each skill names what the MCP cannot do first, so a weaker model does not hallucinate create-requirement / create-release / self-heal.
5. **Report template supplied.** Each workflow ends with an exact output shape so weaker models produce a structured answer instead of rambling.
6. **Platform tool names only.** Reference MCP tools by their platform name (`create_manual_test_run`), never an agent-specific wrapper, so the same instruction works in Copilot/Cursor/Kiro/Windsurf.

## Small-model guardrails (Haiku / small Copilot / Gemini Flash)

- Do one recipe at a time; do not chain R1..R6 in a single prompt.
- Confirm scope (project + repository) before any write.
- After each mutating call, read back (`read_test_case` / `read_test_suite` / `read_execution`) before moving on.
- If a tool errors, report the exact error and stop; do not retry blindly or invent a workaround.

## Copy-paste prompts by intent

Setup: `Set up the Katalon MCP and verify my projects.`
Plan: `Plan testing for sprint 3.2: show coverage gaps and build the executable suite.`
Design: `Design and import atomic manual cases from requirement CEL-6 and link them.`
Manage/trace: `Audit requirement-to-test traceability for project X and list orphan requirements.`
Review: `Review the regression suite for release 3.2 and give a verdict with weak cases.`
Execute: `Run this suite with AI and report pass/fail/blocked.`
Analyze: `Triage execution 8842: product bug vs flaky vs environment, and what to file.`
Release: `Is release 3.2 ready to ship based on the quality metrics?`
Maintain: `Which cases went flaky this month, and repair vs regenerate?`
Cross-verify: `Run this critical suite with AI and with Playwright, then reconcile any disagreement.`
Full chain: `Analyze CEL-6, design and import cases, build a suite, run with AI, and tell me if we can ship.`

## Non-Claude agent notes

- **Copilot / Cursor / Kiro / Windsurf / Cline / Continue:** invoke the skill by its name or `/skill-name`; the MCP tool calls are identical. The generated adapter for each agent carries the same skill body.
- **Codex / ChatGPT:** the plugin declares the MCP in `.mcp.json`; follow the numbered steps exactly, they are model-agnostic.
- **Any agent via AGENTS.md:** read `AGENTS.md`, match the request to a skill description, open that `SKILL.md`, follow it.

### references/requirement-analysis.md

# Requirement Analysis Checklist

Use this checklist before writing tests from requirements.

## Inputs To Gather

- Requirement source: Jira key, Azure item, Katalon requirement ID, pasted text, or URL.
- Target AUT/environment.
- Persona or role.
- Business objective.
- Acceptance criteria.
- Known constraints, data, permissions, and dependencies.
- Sprint/release scope if test assets should be organized by iteration.

## Analysis Output

Produce:

- Requirement summary: what must be true for the feature to be accepted.
- Main flow: happy path from user intent to expected outcome.
- Alternate flows: optional paths, branching choices, pagination, sorting, filtering, retries.
- Negative flows: invalid data, missing data, permissions, empty states, out-of-stock or unavailable state.
- Data matrix: values needed for manual tests.
- Risk matrix: high-risk areas that deserve P0/P1 tests.
- Coverage map: requirement or story -> proposed test cases.

## Katalon Requirement Handling

- Use `find_requirements` to search synced Jira/Azure requirements.
- Use `read_requirement` for a specific requirement by source key or internal ID.
- Use `find_test_cases_by_requirement` to inspect existing coverage.
- Use `link_requirements_to_test_case` after test cases exist.
- Do not claim that the MCP can create requirements; current available tools only find/read/link synced requirements.

### references/unavailable-capabilities.md

# Katalon MCP Capability Boundaries

## Available

- Project discovery: `list_projects`.
- Repository/Test Project discovery: `list_repositories`.
- Requirement discovery: `find_requirements`, `read_requirement`.
- Requirement coverage: `fetch_requirement_data`.
- Test case operations: `create_test_case`, `read_test_case`, `update_test_case`, `duplicate_test_case`, `delete_test_case`, `move_test_case`, `find_test_cases`.
- Test folder operations: `find_test_folders`, `manage_test_folder`.
- Test suite operations: `find_test_suites`, `read_test_suite`, `manage_test_suite`.
- Requirement links: `link_requirements_to_test_case`, `unlink_requirements_from_test_case`, `find_test_cases_by_requirement`.
- Manual execution: `read_auts`, `create_manual_test_run`, `create_manual_ai_session`, `read_manual_ai_session`.
- Automated execution: `find_execution_profiles`, `list_test_cloud_environments`, `build_run_configuration`, `build_schedule`, `schedule_test_run`.
- Execution results: `read_execution`, `read_execution_test_results`, `read_test_result`, `find_test_results`.
- Quality data: requirement, defect, test case, test stability, and configuration coverage fetch tools.
- ALM defects: `find_alm_integration_projects`, `create_defect`.

## Not Directly Available

- Create requirements in Katalon True Platform. Requirements are synced from Jira/Azure and can be found/read/linked.
- Create a formal Test Plan entity. Use test suites/folders/executions as the executable planning structure.
- Guarantee Run with AI completion. The platform may block, fail, or require AUT/account state.
- Inspect AUT pages through Katalon MCP. Use Browser/Playwright for website exploration.
- Create defects without a failed test result ID and ALM integration details.

## Recommended Workarounds

- Requirement creation: create in Jira/Azure first, then sync/find/link in Katalon.
- Test plan: create a named folder and/or test suite, link to sprint/release, and create execution from that suite.
- AUT exploration: use Browser/Playwright to understand the product, then import manual cases into Katalon.
- AI execution blocked: report blocked state with required fixture, AUT, account, or environment action.