test-and-verifylisted

Use this skill whenever tests are to be run or a failure chased down — "run the tests", "run the test suite", "verify this", "check the tests pass", "fix the failing tests", "why is this test failing", or when `execute-plan` needs a task or a `Task X.V` gate verified. Use it even when the request looks like a one-liner — the bounded loop and the honest verdict are the point, not the command. Not for writing a feature or its tests from a plan — use execute-plan. Not for standing up a project's first test runner — use execute-plan. Runs a project's tests, reads the real output rather than the exit code, and fixes what fails — a bounded diagnose-fix-rerun loop that stops after three remediation attempts instead of guessing on, and never weakens a test to reach green. Targets the suite relevant to the work, and adds the type-checker and linter at a phase gate. Reports a plain pass or fail verdict with the exact command it ran, and never edits a plan file — the caller marks the boxes.
melconcoast/code-idea · ★ 1 · Data & Documents · score 75

Install: claude install-skill melconcoast/code-idea

# test-and-verify Runs the tests, reads what actually happened, and fixes what's broken — within a bounded number of attempts, then hands back. ## When this runs - `execute-plan` finishes a task and needs its scenarios proved, or reaches a `Task X.V` phase gate - The user asks for the suite to be run, or for a failing test to be chased down - Never to decide *what* to build, and never to write a feature's first tests from a plan — that's `execute-plan` ## Core philosophy - **A pass you didn't read isn't a pass.** Run the command, read stdout and stderr, and check the counts. A suite that "succeeded" because it collected zero tests, skipped the new ones, or exited 0 on a crash is a failure wearing a green hat. - **Three attempts, then stop.** The loop is bounded on purpose. A fourth attempt is guessing, and guessing costs tokens and makes the diff worse. Hand back with what you know. - **Fix only what the failure names.** Not the code around it, not a style you'd have written differently, not a passing test you find unconvincing. Unrelated findings get reported, never fixed in passing. - **The failure decides what to fix — application code or the test.** These are different bugs, and picking wrong makes both worse. Say which one you concluded and why before you change anything. - **Never edit a plan file.** Not a glyph, not a count, not the Progress Log. This skill produces a verdict; `execute-plan` writes it down. Two writers on one file is how a plan stops being trustwort