testsprite-verify

Runs TestSprite CLI tests against shipped code changes and inspects failure artifacts before reporting completion.

Updated Sep 8, 2026
One-click install
npx skills add https://github.com/parthamehta123/loopcart-checkout-app --skill testsprite-verify-parthamehta123
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: testsprite-verify
Source: https://github.com/parthamehta123/loopcart-checkout-app/tree/main/.claude/skills/testsprite-verify
Command: npx skills add https://github.com/parthamehta123/loopcart-checkout-app --skill testsprite-verify-parthamehta123

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After finishing a feature or fix, developers often report work as done based only on unit tests or code review, missing bugs that only appear for real users. This Skill enforces a verification loop that runs the relevant TestSprite tests through the testsprite CLI against the actual change before declaring completion. ## Core Features & Use Cases - Mandatory verification loop: Requires at least one TestSprite run to a terminal verdict (passed/failed/blocked/inconclusive) for every shipped feature, with a narrow skip list for docs-only and config-only edits. - Test authoring guidance: Drafts frontend plan.json files with reliable planSteps wording rules, or backend Python assertion scripts using injected credentials and dependency declarations (--produces/--needs). - Failure triage: Distinguishes plan-quality problems from real product bugs by inspecting step traces, and downloads failure artifact bundles for root-cause analysis. - Use Case: After fixing a checkout coupon bug in a web app, run the existing TestSprite checkout test against the deployed preview URL with --wait, confirm it passes, and report the verdict with the dashboard link. ## Quick Start Verify my just-finished checkout fix by running the relevant TestSprite test against the deployed preview URL and tell me the verdict.

Frequently Asked Questions about testsprite-verify

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

FAQPage Schema
How do I run a TestSprite test against my code change?

Run `testsprite test run <test-id> --target-url <env-url> --wait --timeout 600` for an existing test, or `testsprite test create --plan-from plan.json --run --wait` for a new frontend test. The `--wait` flag long-polls until a terminal verdict is reached.

How do I test a change that is only running locally?

Use `testsprite test run <test-id> --local <port>` instead of `--target-url`. This tunnels your loopback address to the test runner, works for frontend tests only, and requires an API key with the run:tunnel scope.

When can I skip running TestSprite tests after a change?

Skip only for docs-only edits, pure build/config changes like tsconfig or lint config, or when the repo is not wired to TestSprite at all. Every other code change requires at least one test run to a terminal verdict.

Why did my backend TestSprite test silently pass?

The runner executes the file top-to-bottom and does not auto-discover test functions like pytest. If your `test_*` function is only defined but never called at the end of the file, its assertions never run and the test passes vacuously.

What does exit code 7 mean on a TestSprite test run?

Exit code 7 means the run timed out and should be treated as inconclusive, not a regression. Resume it with `testsprite test wait <run-id>`, except for `--local` runs where the tunnel has closed and you must re-run instead.

How do I handle authentication in backend TestSprite tests?

Never hardcode tokens or API keys in the test script. Configure the credential once on the project with `testsprite project credential`, then spread the auto-injected `__AUTH_HEADERS__` into every authenticated request.