Add 18 Katalon True Platform testing skills

skills/katalon-analyze-failures/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: katalon-analyze-failures
+description: Triage Katalon True Platform/TestOps test failures and file defects. Use when you need to investigate failed test results, classify each failure as product defect vs automation defect vs environment/data issue, cluster failures by common signature, find likely root cause from execution data, and optionally create ALM-linked defects for real product bugs. This is failure diagnosis and defect filing; for the overall ship/no-ship release call use katalon-release-analyze, and for repairing the tests themselves use katalon-test-maintenance. Written for the manual tester and the automation tester looking at a red run and needing to know whether the application broke or the test did.
+---
+
+# Katalon Analyze Failures
+
+Use this skill for the **failure-analysis** part of the report/analysis stage: turn a set of failed results into a diagnosis and, when warranted, filed defects. The core value is **classification** — separating real product bugs from automation and environment noise.
+
+## Availability Boundary
+
+- **Available via MCP:** read results (`read_test_result`, `read_execution_test_results`, `find_test_results`, `read_execution`), defect context (`fetch_defect_data`), ALM discovery + filing (`find_alm_integration_projects`, `create_defect`).
+- **Not directly available:** AI root-cause summarization and automation-error-pattern analytics are TestOps/Studio product features, not MCP calls — narrate their availability, do not claim to call them. `create_defect` requires a **known failed test result ID** and ALM integration details; there is no ID-less defect creation.
+
+## Triage Workflow
+
+```text
++---------------------+     +----------------------+     +----------------------+
+| Collect failures    | --> | Classify each        | --> | Cluster by signature |
+| read results        |     | product/auto/env     |     |                      |
++---------------------+     +----------------------+     +----------------------+
+                                                                   |
+                                                                   v
+                                                         +----------------------+
+                                                         | File defects (asked) |
+                                                         +----------------------+
+```
+
+## Steps and tool rules
+
+1. **Collect the failures.** `find_test_results` (recent/specific) or `read_execution_test_results` for a run; `read_test_result` per failed case for detail.
+2. **Classify each failure** into one bucket:
+   - **Product defect** — the application behaved wrong (assertion on real behavior failed, unexpected error/state). Candidate for a filed defect.
+   - **Automation defect** — the test is wrong (bad locator, timing, stale data, broken step). Route to `katalon-test-maintenance`.
+   - **Environment / data** — infra, account, network, fixture, or AUT-state issue. Route to re-run after fix.
+3. **Cluster by signature.** Group failures with the same error message / step / object so one root cause is not filed as N defects.
+4. **Check existing defects.** `fetch_defect_data` to avoid duplicate filings.
+5. **File defects only when asked and only for product defects.** `find_alm_integration_projects` -> `create_defect` with the failed result ID. Ask before creating unless the user explicitly requested defect filing.
+6. **Report.** Per cluster: classification, likely cause, affected cases, and action (file / repair / re-run).
+
+## Prompt recipes
+
+- `Triage the failures in execution 8842: which are product bugs vs flaky tests vs environment?`
+- `Cluster today's failed results by root cause and tell me what to file.`
+- `File defects for the confirmed product bugs in the checkout suite and link them to the failed results.`
+
+## Hand-offs
+
+- Automation defects / flaky -> `katalon-test-maintenance`.
+- Ship decision from the failure picture -> `katalon-release-analyze`.
+- Coverage gap exposed by a failure -> `katalon-test-plan`.
+
+Read `references/failure-triage.md` before classifying. Consult the orchestrator's `references/unavailable-capabilities.md` for defect-filing boundaries.

skills/katalon-analyze-failures/references/failure-triage.md

@@ -0,0 +1,33 @@
+# Failure triage reference
+
+## Classification signals
+
+| Bucket | Typical signals | Action |
+|---|---|---|
+| Product defect | assertion on real app behavior failed; unexpected app error/state; reproducible across runs and environments | file defect (with failed result ID) |
+| Automation defect | element-not-found / locator error; timing / wait failure; stale test data; step no longer matches UI; passes on re-run without app change | route to `katalon-test-maintenance` |
+| Environment / data | infra/network error; account/permission; missing fixture; wrong AUT state; TestCloud/agent issue | fix environment, then re-run |
+
+Reproducibility is the strongest signal: a failure that repeats across environments and runs leans product; one that vanishes on re-run leans automation/environment.
+
+## Clustering
+
+Group by the tuple `(failing step, error message, object/locator)`. One cluster = one candidate root cause = at most one defect. Report the cluster size so a single bug is not filed N times.
+
+## Defect filing rules
+
+- Only for **product defects**, only when the user asked (or explicitly pre-approved failure filing).
+- Requires a **failed test result ID** — get it from `read_test_result` / `read_execution_test_results`.
+- `find_alm_integration_projects` first if the ALM project/integration IDs are unknown.
+- `fetch_defect_data` to check for an existing defect before creating a duplicate.
+- Never invent a stack trace, defect ID, or ALM project. If the ID or integration is missing, report blocked with the exact missing input.
+
+## Report template
+
+```text
+Cluster 1 — <signature>   (N cases)
+  Classification: product | automation | environment
+  Likely cause:   <one line from result data>
+  Cases:          <ids>
+  Action:         file DEF-xxx | repair (maintenance) | re-run after <fix>
+```

skills/katalon-create-test-cases/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: katalon-create-test-cases
+description: Create, update, organize, and link Katalon True Platform/TestOps manual test cases from a synced requirement key such as CEL-6, a read requirement, or free-text product behavior. Use when you need to analyze requirements, design manual test cases using ISTQB techniques as a reference, check existing Katalon coverage, avoid duplicate test cases, import only missing cases, update or link existing cases, or create/reuse a test suite for newly designed cases. For full requirement-to-execution workflows, combine with or defer to katalon-true-platform-testing. Written for the manual tester who has a written requirement in hand and no cases for it yet.
+---
+
+# Katalon Create Test Cases
+
+Use this skill for the test design and import portion of Katalon True Platform work. Keep the larger `katalon-true-platform-testing` skill available as the end-to-end orchestrator; this skill is only the focused create/update/link workflow.
+
+## Availability Boundary
+
+State the Katalon MCP boundary before promising writes:
+
+- Available: list projects/repositories, find/read requirements, create/read/update/move test cases, find/manage folders, find/read/manage test suites, and link requirements to test cases.
+- Not directly available: create requirements, create a formal Test Plan entity, inspect the live AUT UI, or guarantee downstream AI execution.
+- Workaround for a test plan: create or reuse a named test suite/folder as the executable planning structure.
+
+Read `references/capability-boundaries.md` when the user asks whether Katalon can do a specific operation.
+
+## Resolve Context First
+
+Before mutating Katalon data:
+
+1. Call `list_projects`.
+2. Call `list_repositories`.
+3. Resolve the repository/Test Project from the user's wording, requirement key, or unique available repository.
+
+Rules:
+
+- Treat repository and Test Project as the same resolution target.
+- If exactly one repository exists, use it.
+- If multiple equally plausible repositories remain, ask the user to choose.
+- If the user says "Katalon Cloud" or "cloud repo", prefer a repository named `Katalon Cloud` when present.
+- Do not scan every repository just to avoid asking.
+
+## Analyze Requirement
+
+If the user provides a requirement key, use `find_requirements` or `read_requirement`. If the user provides free text, analyze it locally and only link requirements when a real requirement ID is known.
+
+Output or internally track:
+
+- Requirement intent
+- Personas
+- Main flows
+- Alternate and negative flows
+- Data and environment assumptions
+- Risk areas
+- Coverage recommendations
+
+Read `references/requirement-analysis.md` before analyzing non-trivial requirements.
+
+## Design Coverage
+
+Design manual cases using ISTQB techniques as a reference for coverage (the techniques guide the design; the deliverable is plain platform test cases, not an ISTQB certification):
+
+- Equivalence partitioning for input classes, statuses, roles, filters, and product states.
+- Boundary value analysis for ranges, quantities, prices, dates, pagination, and text lengths.
+- Decision tables for business rules with multiple conditions.
+- State transitions for lifecycle flows such as cart, checkout, status, and execution.
+- Use-case scenarios for realistic end-to-end user journeys.
+- Error guessing for ecommerce, account, permissions, environment, and data risks.
+
+### Make each case atomic
+
+Each test case targets **one validation condition (one acceptance-criteria line)** — but it must still be a **complete, independently runnable flow**, not a single bare assertion.
+
+- "Atomic" describes the *scope under test* (one rule per case), not the step count. Every case walks the real path to that condition: precondition/navigation -> enter the surrounding valid data -> perform the action under test -> verify the expected result. A case that is a lone step like "count the columns" is too thin; lead with the steps to reach and exercise that state so the case runs on its own (and so Run with AI can execute it).
+- Split each input class, each required field, each boundary value, and each error message into its own case. Example: a password rule of "min 8 chars, has a letter, has a number, no spaces" becomes separate cases for too-short (7), exactly-8 valid, letters-only, numbers-only, and contains-space — each one a full fill-the-form-and-submit flow, differing only in the field under test.
+- Cover both the happy-path flow and its edge cases. For every feature, include at least the main success flow plus the boundary and negative variants around it; do not stop at the positive path.
+- Reserve genuinely combined multi-feature cases for true end-to-end scenarios (e.g. register -> log in -> land on dashboard), never as a container for unrelated checks.
+- Why: a case mixing several *conditions* fails as a whole, so the result cannot tell you which rule broke and you lose 1 requirement-line -> 1 test-result traceability. Atomic-scope cases pinpoint the failing rule and map cleanly back to the requirement.
+- Quote expected error and UI strings **verbatim** from the requirement, including any source typos. Flag suspected typos separately; never silently "correct" them in the expected result, or the test will assert behavior the app does not produce.
+
+Read `references/istqb-coverage.md` before creating cases from requirements, and `references/manual-test-case-format.md` before importing several cases.
+
+## Platform Constraints
+
+- Test case **names** accept only letters, numbers, spaces, and `( ) . , _ -`. Avoid other symbols (such as `@`, `:`, `/`) in titles; keep them in descriptions or steps instead. Folder paths may use `/`.
+- Prefer `update_test_case` over delete-and-recreate when adjusting an existing set. Deletion can fail server-side, and updating in place keeps IDs, links, and history intact.
+
+## Check Existing Cases
+
+This step is mandatory before every create/import attempt, including retries after partial failure:
+
+1. If requirement IDs are known, call `find_test_cases_by_requirement`.
+2. Search by requirement key, title keywords, feature area, and target folder with `find_test_cases`.
+3. Read likely matches with `read_test_case` when the title alone is not enough to judge coverage.
+4. Reuse, update, move, or link existing cases when they already cover the behavior.
+5. Create new cases only for uncovered behavior, missing coverage classes, or clearly obsolete/incorrect cases.
+
+Never create a duplicate just because a previous create call failed.
+
+## Create Or Update Cases
+
+Use Katalon tools in this order:
+
+1. `create_test_case` only for uncovered manual cases.
+2. `update_test_case` for revisions, passing all intended updates in one call.
+3. `link_requirements_to_test_case` only after requirement IDs are known.
+4. `read_test_case` after creation or update when verification matters.
+5. `manage_test_folder` or `move_test_case` only when organization is requested or clearly needed.
+
+Use this manual case shape:
+
+- Title
+- Description
+- Pre-condition
+- Steps
+- Expected results
+- Test data
+- Priority
+- Requirement links
+
+## Test Suite Handling
+
+When the user asks to create a test suite/test plan from the cases:
+
+1. Search existing suites with `find_test_suites` before creating anything.
+2. Read likely matching suites with `read_test_suite`.
+3. Reuse the matching suite and add missing cases instead of creating a duplicate.
+4. Create a new suite with `manage_test_suite` only when no suitable suite exists.
+5. Verify the final suite with `read_test_suite`.
+
+Report what was reused, updated, newly created, linked, and left uncovered.

skills/katalon-create-test-cases/references/capability-boundaries.md

@@ -0,0 +1,32 @@
+# 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.

skills/katalon-create-test-cases/references/istqb-coverage.md

@@ -0,0 +1,64 @@
+# 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.