ci-single-check-validation

Diagnoses a single failing CI check by running the equivalent local gate and attributing findings to files.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill ci-single-check-validation-vilnacrm-org
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ci-single-check-validation
Source: https://github.com/VilnaCRM-Org/claude-plugins/tree/main/plugins/react-frontend-sdlc/skills/ci-single-check-validation
Command: npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill ci-single-check-validation-vilnacrm-org

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When exactly one CI check on a pull request turns red while everything else is green, it is ambiguous whether the failure is a real finding in your diff, pre-existing debt, or a transient infrastructure issue. This Skill settles the question with local evidence before you fix, re-run, or escalate. ## Core Features & Use Cases - Local gate reproduction: Maps the failing check to its underlying tool and runs the full local equivalent (lint, unit, E2E, mutation targets) rather than a narrowed invocation. - Finding attribution: Attributes every finding to a file and compares it against the diff to classify the failure as environmental, a real regression, or pre-existing debt. - Escalation path: Defines when to hand off to infrastructure-failure diagnosis, with the evidence (commands, exit codes, runner logs) needed for an actionable re-run request or issue. - Use Case: A Playwright shard fails on your PR with a timeout while all other checks pass. Run the local E2E target, confirm a clean result, and record the evidence in the PR thread to justify a re-run. ## Quick Start Ask the assistant to validate why the single failing CI check on my pull request is red while all other checks are green.

Frequently Asked Questions about ci-single-check-validation

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

FAQPage Schema
How do I tell if a failing CI check is a real bug or a flaky failure?▼

Run the full local equivalent of the failing check, such as the lint or E2E make target, and attribute every finding to a file. If the local run is clean, the failure is environmental; findings in changed files indicate a real regression.

What should I do when one CI check fails but all others pass?▼

Identify the exact tool behind the check, run its full local equivalent without narrowing to changed files, then compare findings against your git diff. Record the command, exit code, and attribution in the pull request thread before deciding to fix, re-run, or escalate.

Why does my local lint run pass when CI fails on the same code?▼

A narrowed local invocation, such as linting only changed files, can disagree with CI's aggregate run. Run the complete aggregate target that CI executes so both environments evaluate the same scope.

When should I escalate a CI failure instead of re-running it?▼

Escalate when the same check fails again on a fresh run with no code change, fails on other branches too, or fails locally only under the container path. File the issue with both local evidence and the runner's step name, exit code, and error text.

Is it acceptable to re-run a flaky CI check until it passes?▼

No. Re-running until green without local validation hides what the check is reporting. Prove the failure is environmental with a clean local run first, and never lower thresholds or exclude flagged files to make the check pass.