mcpField
L
ln-514-regression-checker

ln-514-regression-checker

github.com/levnikolaevichTesting & quality58455 installsUpdated 2d ago
Repository

About ln-514-regression-checker

A regression-checking skill for quality workflows that runs a project's existing test suite after code changes. It detects the test framework and follows the project runbook, reporting results without changing tests or status.

Key features

  1. 01Detect test frameworks and test directories
  2. 02Prioritize the project runbook
  3. 03Run the full test suite
  4. 04Parse pass and failure results
  5. 05Return a verdict and comment on Linear

Use cases

  1. 01Check for regressions after implementation changes
  2. 02Provide test results for a quality gate
  3. 03Identify failing tests and summarize logs

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/levnikolaevich/claude-code-skills --skill ln-514-regression-checker

After installing, type/ln-514-regression-checkerin Claude Code to confirm it loaded.

Bundled filesreferences/pytest_configuration.md

Details

From the project README

Paths: File paths (shared/, references/, ../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.

Regression Checker

Runs the existing test suite to ensure no regressions after implementation changes.

Purpose & Scope

  • Detect test framework (pytest/jest/vitest/go test/etc.) and test dirs.
  • Execute full suite; capture results for Story quality gate.
  • Return PASS/FAIL with counts/log excerpts; never modifies Linear or kanban.

When to Use

  • Invoked by ln-510-quality-coordinator Phase 7
  • Code quality check passed

Workflow (concise)

  1. Auto-discover test framework per shared/references/ci_tool_detection.md Command Registry (Test Frameworks section).
  2. Read docs/project/runbook.md — get exact test commands, Docker setup, environment variables. Runbook commands take priority over auto-detection (per ci_tool_detection.md Discovery Hierarchy).
  3. Build appropriate test command; run with timeout (5min per ci_tool_detection.md); capture stdout/stderr.
  4. Parse results: passed/failed counts; key failing tests.
  5. Output verdict JSON (PASS or FAIL + failures list) and add Linear comment.

Critical Rules

  • No selective test runs; run full suite.
  • Do not fix tests or change status; only report.
  • Language preservation in comment (EN/RU).

Definition of Done

  • Framework detected; command executed.
  • Results parsed; verdict produced with failing tests (if any).
  • Linear comment posted with summary.

Reference Files

  • Risk-based limits used downstream: ../shared/references/risk_based_testing_guide.md
  • CI tool detection: shared/references/ci_tool_detection.md

Version: 3.1.0 Last Updated: 2026-01-09

Comments

Markdown supported