---
name: branch-review-check-testlink
description: "Open a TestLink test case via MCP and verify that the changed autotest in the branch covers all required steps and expected results. Use when: review autotest against TestLink, compare test implementation with TestLink case, verify coverage of written test, проверить автотест по TestLink, сверить тест с тест-кейсом, проверить что автотест покрывает шаги тест-кейса."
argument-hint: "TestLink test case ID or changed test file/scope"
---

# Branch Review: Check TestLink Coverage

This skill verifies that a written autotest actually checks everything required by the authoritative TestLink test case.

## When to Use

- The branch adds or changes autotests tied to a TestLink case
- The user explicitly asks to compare a test file with a TestLink case
- The diff contains a recognizable TestLink reference such as `KMD-123`, `PRJ-42`, or a comment, marker, title, docstring, or test name that maps to a test case

## Core Rule

Do not assume that a test is complete just because it exists.

You must fetch the TestLink case via MCP, read the written autotest, and compare:
- preconditions
- scenario steps
- expected results
- negative and branching behavior when the TestLink case requires it

## Procedure

### Step 1 — Resolve the TestLink Case ID

Find the most reliable case identifier in this order:
1. explicit user-provided case ID
2. exact TestLink ID found in changed test code, comments, docstrings, titles, markers, fixture names, or nearby docs
3. exact TestLink ID found in commit or branch-related text already provided in context

Accepted formats:
- numeric internal ID, for example `1831`
- external ID, for example `KMD-1831`

If there is no reliable ID, stop this skill and report:
- no TestLink case could be resolved from the branch
- what evidence was checked

### Step 2 — Fetch the Authoritative Test Case

Call TestLink MCP to load the case.

Use:
- `external_id` for prefixed identifiers such as `KMD-1831`
- `test_case_id` for plain numeric identifiers

Extract at minimum:
- `id` and `external_id`
- `name`
- `summary`
- `preconditions`
- `steps[].step_number`
- `steps[].actions`
- `steps[].expected_results`

If the case is not found, report it and stop this skill.

### Step 3 — Read the Written Test Thoroughly

Read the changed test file and any directly related helpers or fixtures that are necessary to understand what is actually asserted.

Determine:
- what setup the test performs
- what actions it executes
- what it asserts explicitly
- what it only implies but does not verify
- what parts of the TestLink case are not covered at all

Be strict here:
- execution of a step is not the same as verification of a result
- logging or comments are not assertions
- helper names do not count as coverage unless the underlying assertion is visible or can be traced with confidence

### Step 4 — Build a Coverage Matrix

Map the TestLink case to the written test.

For every TestLink step, classify coverage as one of:
- `Covered` — the test clearly performs the step and verifies the expected result
- `Partial` — the test performs the step but misses all or part of the required verification
- `Missing` — the step or expected result is not covered
- `Unclear` — likely covered indirectly, but the assertion path cannot be confirmed from the code

Also assess preconditions:
- fully represented
- partially represented
- missing

### Step 5 — Produce Review Findings

Output findings focused on concrete gaps.

Template:

```md
## TestLink Coverage Check

Case: <external_id or id> — <title>
Source test: <file or symbol>

### Coverage Summary
- Preconditions: covered/partial/missing
- Steps covered: X/Y
- Partial: N
- Missing: N
- Unclear: N

### Coverage Matrix
1. Step <N>: <short action>
   - expected: <short expected result>
   - status: Covered | Partial | Missing | Unclear
   - evidence: <test function / assertion / helper>

### Gaps
1. <gap title>
   - why it matters: ...
   - recommended fix: ...
   - safe to auto-apply: yes/no
```

## Review Guidance

- Treat `Missing` and `Partial` coverage as review findings
- Escalate to `Critical` when a missing check can hide a regression in the core scenario
- Escalate to `Important` when the flow exists but the expected result is not asserted
- Put naming-only or traceability-only improvements into `Optional` unless they block reliable mapping to TestLink

Do not edit files in this skill. It only produces coverage analysis for the proposal stage.