jaktestowac/analyzing-regression-scope
skills/analyzing-regression-scope/SKILL.md
Analyzes diffs, changed files, hotfixes, and release candidates to identify where regression risk spreads and what must be retested first. Use when scoping retest after a change, reviewing QA impact for a pull request, or building a minimal confidence suite for release validation.
$ install --global
skillsauthnpx skillsauth add jaktestowac/awesome-copilot-for-testers analyzing-regression-scopeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jul 8, 2026, 8:16 AM130.1s2 files scanned
SKILL.md
- name:
- analyzing-regression-scope
- description:
- Analyzes diffs, changed files, hotfixes, and release candidates to identify where regression risk spreads and what must be retested first. Use when scoping retest after a change, reviewing QA impact for a pull request, or building a minimal confidence suite for release validation.
- argument-hint:
- Diff, changed files, PR summary, release notes, critical flows, and any known risk areas
- user-invocable:
- true
Analyzing Regression Scope
Use this skill when the real question is not "how do we test everything?" but "what must we retest now, and why?" It is built for risk-aware retest planning after code changes, configuration shifts, dependency updates, or release packaging.
When to Use
- analyze regression scope after a bug fix or feature change
- decide what must be retested for a hotfix
- prepare a release confidence suite from a diff or PR
- explain QA impact of shared component or config changes
- separate must-retest areas from nice-to-have regression coverage
Operating Principles
- Change surface first - understand what changed before proposing retest coverage.
- Risk spreads through dependencies - shared modules, auth, data mapping, and configuration often widen impact.
- Direct is not the whole story - the changed file is only the start; adjacent behaviors matter too.
- Small believable packs beat fake completeness - a focused confidence suite is better than a giant list nobody will execute.
- Unknown impact stays visible - if propagation is unclear, log it as an open question instead of bluffing.
Workflow
Phase 0: Frame the input
Use the best available source:
- changed files
- a diff or PR summary
- release notes
- a hotfix description
- a list of touched components or endpoints
Capture any known critical journeys, environments, or roles that matter.
Phase 1: Map the change surface
Break the change into four layers:
- Directly changed behavior - the feature, endpoint, or component that was edited
- Adjacent behavior - nearby flows that call, render, or depend on the changed surface
- Shared risk - utilities, configuration, auth, layout, data mapping, or common services reused elsewhere
- State and data risk - migrations, caching, permissions, synchronization, or environment-specific behavior
Phase 2: Classify retest risk
Use a practical three-level scale:
| Risk | Use when | | --- | --- | | High | Direct change on a critical path, shared core module, data integrity flow, auth, checkout, notifications, or high-traffic workflow | | Medium | Indirect dependency, shared helper, UI shell, validation logic, or meaningful edge-case exposure | | Low | Isolated change with narrow blast radius and no obvious shared-path impact |
Phase 3: Build the regression pack
Organize the result into four buckets:
- Must retest - confidence blockers; skipping these would be reckless
- Should retest - meaningful adjacent coverage if time allows
- Can sample - smoke-level checks instead of full retest
- Can defer with caution - lower-impact items worth tracking, not necessarily executing now
For every important area, include:
- why it is affected
- what to retest
- what data or environment setup is needed
- whether the coverage should stay manual or move into automation later
Phase 4: Produce the report
Use ./resources/regression-scope-template.md when possible.
A strong report includes:
- a short change summary
- a risk-ranked regression table
- a minimal confidence suite
- explicit open questions and blind spots
Common Failure Modes
- equating changed files with full regression scope
- producing a huge retest list with no priority
- ignoring shared components, config, or auth ripple effects
- forgetting data setup or role-specific behavior
- treating uncertainty as low risk without explanation
Resource Map
./resources/regression-scope-template.md- structure for regression reports and confidence suites
Related Skills
designing-functional-tests- when the regression result should expand into manual scenarios or test casesverifying-acceptance-criteria- when the question becomes whether the feature now meets its stated contractrequirements-test-coverage-mapper- when broader traceability matters more than tactical retest scopecode-review-advanced- when the regression assessment should be paired with code-level risk review
Definition of Done
This skill is complete when:
- the change surface is explained clearly
- high, medium, and low regression areas are separated
- the must-retest pack is believable and prioritized
- open questions and blind spots are explicit
- the output can guide a tester or release lead immediately
Related Skills
jaktestowac/testing-agent-skills
testing
VerifiedTrustedCommunity
Tests the customization assets themselves - skills, prompts, custom agents, instructions - the way a product is tested: activation cases that check an asset fires when it should and stays quiet when it should not, output-contract cases, safety cases, collision cases between assets competing for the same trigger, a weighted rubric scored blind, and a baseline-versus-candidate gate before an edit ships. Use when a skill is edited and nobody knows whether behaviour changed, when two skills fight over the same request, when a description is being tuned for discoverability, when a collection has grown past manual spot-checking, or when the request mentions skill evals, prompt regression, or "does this skill actually work".
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/communicating-quality-findings
development
VerifiedTrustedCommunity
Shapes QA output for the person who has to act on it: result and blocker in the first two lines, one decision per report, findings ordered by what they cost, the long artifact in a file and the decisions in the message, and magnitude stated in units the reader can count. Use when a report is accurate but nobody acts on it, when a finding set is too long to read under time pressure, when the same findings must be retold for a developer, a release manager, and an on-call engineer, or when the request mentions "too long", "make this readable", "just tell me what to do", "so what", or "summarize this for stakeholders". Pairs with unslop-answers, which makes the same report honest.
113SKILL.mdUpdated Aug 29, 2026
jaktestowac/verifying-change-coverage
testing
VerifiedTrustedCommunity
Verifies that the lines and branches a change actually touched are executed by tests, using LCOV or Cobertura diff coverage instead of whole-repo percentages, and escalates uncovered high-risk changes into a blocking finding. Use when a pull request needs a coverage gate that unrelated tests cannot satisfy, when total coverage looks healthy but the diff is untested, when wiring diff coverage into CI, or when someone claims a change is covered because the suite is green.
113SKILL.mdUpdated Aug 26, 2026
jaktestowac/unslop-tests
development
VerifiedTrustedCommunity
Cuts AI tells from test code: tests that pass without proving anything, tautological assertions, mock-only tests, hardcoded waits, coverage theater, vague names, swallowed errors, retries used as fixes. Use whenever test code is written, changed, or reviewed, including tests produced as a side effect of a feature task, and when the request mentions "review these tests", "are these tests any good", "this test always passes", "this suite is flaky", or "clean up these tests". Must always apply to test code.
113SKILL.mdUpdated Aug 26, 2026