feat: Add new agents and skills for Docker, TestLink, and OpenWrt
- Introduced "Docker Build & Test Engineer" agent for building and testing Docker images. - Added "TestLink Autotest Engineer" agent for generating and verifying autotests from TestLink cases. - Created "Branch Review Engineer" agent for reviewing branch diffs and proposing improvements. - Developed "OpenWrt VPN & Network Engineer" agent for designing and implementing OpenWrt networking with VPN. - Established a structured directory for agents, skills, prompts, instructions, and hooks under `.github/`. - Implemented detailed skills for branch review processes, including reading code, analyzing improvements, and applying changes. - Added skills for OpenWrt network discovery, VPN routing, and hardening. - Created README files for better documentation and navigation of the repository structure.
This commit is contained in:
ВяткинАртём
@@ -0,0 +1,133 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user