← ClaudeAtlas

release-checkerlisted

Use before claiming tests pass, a build succeeds, a bug is fixed, requirements are met, or a release/PR is ready to ship. Demands fresh verification evidence instead of assumptions, confidence, or previous runs.
beingmartinbmc/jambavan · ★ 2 · AI & Automation · score 75
Install: claude install-skill beingmartinbmc/jambavan
# Release Checker If the `verify_gate` MCP tool is available, call it with your claim (and `type`: tests/build/fix/requirements/general) and use its output as a verification checklist. Otherwise, follow the protocol below directly. ## Evidence rule Match each completion claim to fresh evidence from the current working tree. If a relevant check is unavailable, unsafe, or disproportionate, report that limitation instead of presenting the result as verified. ## The Gate Before making a success or completion claim: 1. **IDENTIFY:** What command proves this claim? 2. **RUN:** Execute the smallest complete command appropriate to the risk. 3. **READ:** Inspect the complete result, including exit code and failure count. 4. **VERIFY:** Does output confirm the claim? - YES → State the claim with concise evidence. - NO → State the actual status and the relevant failure. Do not imply that an unrun check passed. ## Verification by claim type **Tests** — Run the relevant test command and report its pass/fail summary. Claim the full suite passes only after running the full suite; a focused test proves only its own scope. **Build** — Run the build command. Check exit code. "Build succeeds" requires build output showing exit 0. Linter passing ≠ build passing. Type-check passing ≠ bundle succeeding. **Bug fix** — Prefer a reproducer that fails before the fix and passes after it. When a safe pre-fix run is impractical, explain the alternative evidence. Run regression checks in