regression-testing

Executes CI regression suites, classifies failures, and produces GO/NO-GO release verdicts.

Updated Aug 31, 2026
One-click install
npx skills add https://github.com/ahuaracab/test-genesis --skill regression-testing-ahuaracab
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: regression-testing
Source: https://github.com/ahuaracab/test-genesis/tree/main/.agents/skills/regression-testing
Command: npx skills add https://github.com/ahuaracab/test-genesis --skill regression-testing-ahuaracab

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Running regression, smoke, or sanity suites in CI is only half the job — teams still need to monitor long GitHub Actions runs, download Allure and Playwright artifacts, decide whether each failure is a real regression or a flake, and turn all of that into a defensible release decision. This Skill automates that entire Execute → Analyze → Report pipeline so release readiness is based on evidence, not guesswork. ## Core Features & Use Cases - CI Suite Orchestration: Triggers regression, smoke, or sanity workflows via gh workflow run, monitors runs to completion with background subagents, and downloads Allure, evidence, and Playwright artifacts in parallel. - Failure Classification: Applies a six-bucket decision tree (REGRESSION, FLAKY, KNOWN ISSUE, ENVIRONMENT, NEW TEST, KNOWN-BLOCKED) with a >20% flakiness rule over historical runs, excluding blocked tests from the gating pass rate. - GO / CAUTION / NO-GO Verdicts: Computes a weighted release score with hard vetoes (any @critical failure, HIGH/CRITICAL regression, or pass rate below 90%) and files confirmed defects in Jira with the mandatory field matrix. - Use Case: Before a production deploy, ask the assistant to run the staging regression suite; it triggers the workflow, waits out the 20–60 minute run, classifies every failure, and delivers an executive quality report with a release verdict saved under .context/reports/. ## Quick Start Ask the assistant to run the regression suite on staging and tell you whether the build is ready to release.

Frequently Asked Questions about regression-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run a regression suite in GitHub Actions and get a release decision?

Trigger the workflow with gh workflow run regression.yml passing the environment, capture the run ID, and monitor it with gh run watch. After completion, download the Allure artifacts, classify failures, and apply the scoring matrix to get a GO, CAUTION, or NO-GO verdict.

How to tell if a failed test is a regression or a flaky test?

Check the test's history over the last 10 runs on unchanged builds: a failure rate above 20% means FLAKY, while a test that passed in the last 5 runs and now fails after a code change is a REGRESSION. Never classify as REGRESSION without history evidence.

What is the difference between regression, smoke, and sanity test suites?

Regression runs the full suite in 20-60 minutes for pre-release validation, smoke runs only @critical tests in 2-5 minutes as a post-deploy health check, and sanity targets one feature, file, or grep pattern in 1-10 minutes for focused verification.

Does this skill work with Allure reports from CI?

Yes, it downloads the merged-allure-results artifact from the CI run and parses Allure result JSON as the primary source of truth, falling back to Playwright report.json and raw logs. Allure 3 runs locally via bunx without a global install.

When should I not use regression-testing for a QA task?

Do not use it to write new regression tests, which belongs to the test-automation skill, or for manual fix verification of a single ticket, which belongs to sprint-testing. It only executes existing suites and analyzes their results.

Why are some failing tests excluded from the pass rate calculation?

Tests tagged @blocked:{BUG-KEY} with a test.fail marker are deliberately parked behind an already-filed bug, so they are classified as KNOWN-BLOCKED and excluded from the gating pass rate. They are listed separately in the report with their blocking bug key.