github-copilot/.github/skills/branch-review-check-testlink/SKILL.md

name, description, argument-hint

name	description	argument-hint
branch-review-check-testlink	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, сверить тест с тест-кейсом, проверить что автотест покрывает шаги тест-кейса.	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:

## 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.