Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →bartsoj/VERIFICATION.md
Verify a running application by interacting with it as a QA tester.
Passed 16 of 19 test cases with the skill, and 7 of 19 without it.
and 8 more in the full report
10 fixed9 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
During setup, the backend server process crashed within 10 seconds of starting because `PORT` was unbound, so zero user scenarios could be executed. What is the overall `verdict` field value in the YAML frontmatter?
| Checked | Without skill | With skill |
|---|---|---|
| Assigns fail to the verdict field. | Missed | Passed |
The instructions your model reads when the skill loads.
Produce a VERIFICATION.md that documents the results of testing a running application by actually using it — launching it, interacting with its interface (browser, mobile emulator, or CLI), and recording pass/fail outcomes for each scenario. This is QA testing through interaction: the skill does not read or review source code. It starts the application and operates it as an end user would, then reports what works and what does not.
The defining discipline — and the commonest violation — is evidence per scenario: every pass/fail claim is backed by a concrete artefact (a screenshot at the assertion point, a command output, a response body, a log line). The commonest violation is marking a scenario pass because the page loaded or the process did not crash, without ever verifying the specific behaviour the scenario describes. A scenario "User can log in with valid credentials" passes only when the post-login state is observed and captured — not when the login page merely renders.
package.json scripts (dev, start, serve), Makefile targets, docker-compose.yml services, Cargo.toml, go run targets, pyproject.toml, or README instructions. If the application is already running, the user provides the URL or entry point and startup is skipped entirely.web, mobile, cli, or mixed. Discovery mechanism: infer from the start command (web frameworks → web, adb/simulator flags → mobile, binary invocations → cli, combined startup → mixed) and from codebase structure (presence of public/, ios/, android/, cmd/).http://localhost:3000, a CLI command name). Discovery mechanism: extract from the start command output, then fall back to common defaults (localhost:3000, localhost:8080, localhost:5173).Verification proceeds in four phases: discovery, setup, testing, and documentation.
Determine three things before touching the application.
1. What to test. Parse verification scenarios from the user's input. Each scenario becomes a test case with four attributes:
| Attribute | What it captures |
|---|---|
| Name | Descriptive label, e.g., "User can log in with valid credentials" |
| Steps | Ordered interaction sequence: navigate here, click this, type that, submit |
| Expected outcome | Observable result: text appears, page changes, exit code is 0, file is created |
| Evidence strategy | What to capture: screenshot, command output, console log, response body |
If the user's input is high-level ("verify login works"), decompose it into concrete steps using your knowledge of the application type and common UX patterns. If the application type is unknown at this point, defer step decomposition to Phase 3 after startup reveals the interface.
2. How to start the app. If the user provided start instructions or a URL to an already-running app, use those. Otherwise, explore the codebase:
test cases passed, vs 7 / 19 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.