pr-test-analyzer

Analyzes test coverage quality and completeness in Pull Requests.

Updated Apr 4, 2026
One-click install
npx skills add https://github.com/juanjo-zurich/juarvis-v4 --skill pr-test-analyzer-juanjo-zurich
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: pr-test-analyzer
Source: https://github.com/juanjo-zurich/juarvis-v4/tree/main/plugins/pr-review/skills/pr-test-analyzer
Command: npx skills add https://github.com/juanjo-zurich/juarvis-v4 --skill pr-test-analyzer-juanjo-zurich

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull Requests often ship with insufficient or fragile tests, letting critical bugs and regressions slip into production. This Skill reviews the test coverage of a PR, identifies critical gaps, and evaluates whether existing tests actually protect against real failures. ## Core Features & Use Cases - Coverage Gap Detection: Identifies untested error-handling paths, missing edge cases, uncovered business logic branches, and absent negative test cases. - Test Quality Evaluation: Assesses whether tests verify behavior and contracts rather than implementation details, and whether they follow DAMP principles. - Prioritized Recommendations: Rates each suggested test from 1 to 10 by criticality, with concrete examples of the failures it would catch. - Use Case: After opening a PR that adds a new payment validation flow, run this analyzer to confirm that error paths, boundary conditions, and concurrent behavior are covered before merging. ## Quick Start Review the test coverage of my current Pull Request and list any critical gaps with priority ratings.

Frequently Asked Questions about pr-test-analyzer

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

FAQPage Schema
How do I check test coverage quality in a Pull Request?▼

Run a test coverage analysis on the PR diff to map tests against changed functionality. The analyzer identifies untested error paths, missing edge cases, and uncovered business logic, then rates each gap by criticality from 1 to 10.

What makes a good test for code review purposes?▼

Good tests verify behavior and contracts rather than implementation details, survive reasonable refactoring, and follow DAMP principles with descriptive meaningful phrases. They should fail when behavior changes unexpectedly, not when internal structure changes.

Should I aim for 100% code coverage in my PRs?▼

No, this analysis focuses on behavioral coverage of critical paths rather than line coverage metrics. It prioritizes tests that prevent real production failures like data loss or security issues over trivial getters and setters.

When should I not add a suggested test?▼

Skip suggestions when existing integration tests already cover the scenario, when the code is trivial without logic, or when the cost of maintaining the test exceeds its regression-prevention value. The analyzer explicitly considers cost-benefit tradeoffs.

How are test gap priorities rated in the analysis?▼

Gaps are rated 1-10 by criticality: 9-10 for functionality risking data loss or security issues, 7-8 for user-visible business logic errors, 5-6 for edge cases, and 1-4 for optional completeness improvements.