github-copilot/skills/testlink-decompose/SKILL.md

name, description, argument-hint

name	description	argument-hint
testlink-decompose	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'.	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.

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