green-gate-never-examined-the-case

Diagnoses CI gates and tests that report green without examining the case they guard.

1|Updated Apr 16, 2026
One-click install
npx skills add https://github.com/wan-huiyan/claude-ecosystem-hygiene --skill green-gate-never-examined-the-case-wan-huiyan
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: green-gate-never-examined-the-case
Source: https://github.com/wan-huiyan/claude-ecosystem-hygiene/tree/main/plugins/green-gate-never-examined-the-case
Command: npx skills add https://github.com/wan-huiyan/claude-ecosystem-hygiene --skill green-gate-never-examined-the-case-wan-huiyan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? A check that never ran, ran on the wrong object, or ran on trivially passing input reports exactly the same green status as a genuinely passing check. This Skill helps you detect and fix gates, tests, and CI steps whose "clean" result means "nothing was actually examined" — before the bug they guard ships anyway. ## Core Features & Use Cases - Five measured failure mechanisms: scope excludes the guarded case (disabled objects), malformed input makes the check succeed trivially, errors land on an unread channel (stderr vs stdout), plumbing defaults silently kill an input (shallow clones), and a guard fires but fixing forward leaves the damage in place. - Two-clause verification test: make the check fail on purpose once, and check what the wrong state already cost before clearing it. - Review checklist and baselining guidance: a checklist for new or inherited checks, plus how to baseline a gate that ships red so it fails only on new divergence with verified (not plausible) reasons. - Use Case: Before trusting a release workflow, a CI gate, or a test you have never watched fail, walk the checklist — e.g., verify a paths: ['VERSION'] release filter actually triggers, and confirm via gh release view that the release exists rather than trusting the green tick. ## Quick Start Ask the assistant to audit a specific CI gate or test using the green-gate checklist and make it fail on purpose once to prove it can fail.

Frequently Asked Questions about green-gate-never-examined-the-case

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

FAQPage Schema
How do I verify a CI gate actually works?

Make the check fail on purpose once and watch it go red. A gate nobody has seen fail only proves it printed something, not that it can fail. Record the failing output somewhere durable for future reference.

Why does my CI check pass when it should fail?

Common causes include scope that excludes the guarded case (e.g., disabled objects), malformed input that makes the check succeed trivially, errors written to stderr while the gate reads stdout, or a shallow clone silently emptying one input source.

How do I check a GitHub Actions release actually happened?

Read the step's output, not its green tick — a skipped release and a created release can both exit 0. Run gh release view v<version> and inspect which branch line the log printed to confirm the release exists.

Does actions/checkout fetch full git history by default?

No. actions/checkout@v4 without fetch-depth: 0 creates a depth-1 clone, so commands like git log --follow see only one commit. Any gate depending on git history must set fetch-depth: 0 or assert its inputs are non-empty.

When should I baseline a gate instead of fixing all findings?

Baseline when a new gate against an existing repo reports historical instances that are not today's regression. Record known states as accepted with verified reasons in a baseline file, and fail only on new divergence — never record a plausible but unverified cause.

When is this skill not the right tool?

It is not for measuring an existing test suite's catch rate over history — that is test-effectiveness-auditor's job — and not for flaky tests. It targets a single check that cannot fail on the specific case that prompted its creation.