---
name: testlink-decompose
description: "Decompose a TestLink test case into autonomous mini-tests for AI processing and autotest generation. Use when: user provides a TestLink test case number or ID and wants to split it into independent end-to-end mini-tests. Triggers: 'decompose test', 'split test case', 'mini-tests', 'generate autotests from test case', 'TestLink test number', 'break down test', 'разбей тест', 'декомпозируй тест-кейс', 'мини-тесты из TestLink'."
argument-hint: "TestLink test case ID — numeric (e.g. 99) or external (e.g. PRJ-5)"
---

# TestLink Test Case Decomposer

Fetches a test case from TestLink via MCP and breaks it down into autonomous mini-tests,
each ready for AI processing and automated test generation.

## When to Use

- User provides a TestLink test case number
- A large test needs to be split into independent scenarios
- Preparing a test case for autotest generation
- Analyzing scenario coverage within a single test case

## Procedure

### Step 1 — Fetch the Test Case from TestLink (MCP)

Call `mcp_testlink_get_test_case` to retrieve the full test case.

Determine the correct parameter from what the user provided:
- **Plain number** (e.g. `99`, `1234`) → pass as `test_case_id` (integer)
- **PREFIX-NUMBER** (e.g. `PRJ-5`, `KMD-42`) → pass as `external_id` (string)

If the user's input is ambiguous (no prefix, but looks like it could be external):
1. First try `test_case_id`
2. If not found, ask the user for the full external ID (e.g. `PRJ-99`)

Fields to extract from the response:
- `id` and `external_id` — identifiers (use `external_id` as the display ID in output)
- `name` — test case title
- `summary` — description / objective
- `preconditions` — preconditions
- `steps[]` — array of steps: `step_number`, `actions`, `expected_results`
- `importance` — priority (1=Low, 2=Medium, 3=High)
- `status` — design status

If MCP returns an error or the test case is not found — report to the user and stop.

### Step 2 — Analyze the Content

Analyze the test case steps and identify logical groups using these criteria:

1. **Change of tested function** — steps test a different feature, API, or screen
2. **Change of scenario** — steps describe an independent user journey
3. **Execution independence** — the group can run without the other steps

Each logical group becomes one mini-test.

Rules:
- Setup/Teardown steps (data creation, login) → `preconditions` of the mini-test
- If all steps are inseparable → one mini-test equals the original test case
- Minimum number of mini-tests: 1

### Step 3 — Decompose into Mini-Tests

For each logical group, create a mini-test strictly following the format in
[references/mini-test-format.md](./references/mini-test-format.md).

Numbering and reference rules:
- Mini-test ID: `{ORIGINAL_ID}-MT{N}` — e.g. `TC-1234-MT1`
- `source_steps` — step numbers from the original that are included in this mini-test
- Step numbering inside a mini-test starts from 1 (do not preserve original numbers)

### Step 4 — Output the Structure

Output in the following order:

```
# Decomposition of Test Case {ORIGINAL_ID}: {ORIGINAL_TITLE}

> Original test split into {N} mini-test(s).
> Priority: {High/Medium/Low} | Status: {status}
> Original preconditions: {preconditions or "None"}

---

{mini-test 1 per format from references/mini-test-format.md}

---

{mini-test 2 per format from references/mini-test-format.md}

---
```

### Step 5 — Summary Table

After all mini-tests, append a summary table:

| Mini-Test ID | Title | Original Steps | Ready for Autotest |
|---|---|---|---|
| TC-XXXX-MT1 | ... | 1–3 | ✅ |
| TC-XXXX-MT2 | ... | 4–6 | ⚠️ Needs clarification |

Readiness markers:
- ✅ — steps are atomic, expected results are measurable
- ⚠️ — ambiguous steps or vague expected results