verify

Verify code changes by running the application and capturing observable runtime behavior.

9|2|Updated May 3, 2026
One-click install
npx skills add https://github.com/Miasin-Labs/jfc --skill verify-miasin-labs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: verify
Source: https://github.com/Miasin-Labs/jfc/tree/main/crates/jfc-agents/builtin-skills/claude-2.1.167/frontmatter-skills/verify
Command: npx skills add https://github.com/Miasin-Labs/jfc --skill verify-miasin-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code review and CI tests alone cannot prove a change actually works for real users. This Skill closes that gap by driving the running application through its real interface — CLI, server, GUI, or library boundary — and capturing concrete evidence of behavior. ## Core Features & Use Cases - Runtime Verification: Builds and launches the app, drives the changed code path through its real user-facing surface, and captures stdout, responses, or screenshots as evidence. - Adversarial Probing: Goes beyond the happy path by testing edge cases like empty flags, malformed requests, Ctrl-C interrupts, and repeated state operations. - Structured Verdict Reports: Produces PASS, FAIL, BLOCKED, or SKIP verdicts with step-by-step observations, findings, and replayable evidence. - Use Case: A reviewer asks you to confirm a PR fixing a CLI flag actually works. You run the binary with the new flag, probe it with an empty value, capture the output, and report a PASS with evidence. ## Quick Start Verify that the changes in this pull request actually work by running the app and observing its behavior.

Frequently Asked Questions about verify

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

FAQPage Schema
How do I verify a code change actually works before merging?

Run the application and drive the changed code through its real user-facing surface, such as the CLI command, API route, or GUI screen. Capture the output as evidence and probe at least one adjacent edge case before issuing a verdict.

Should I run tests or typechecks to verify a fix?

No. Running tests only proves CI works, not that the change behaves correctly for users. Verification means launching the app and observing behavior at the surface where a human or program meets the change.

What counts as a runtime surface for verification?

A surface is where a user meets the change: a terminal for CLI tools, a socket for servers, pixels for GUIs, or the public package boundary for libraries. Internal functions are not surfaces; follow their callers to the real interface.

What if a change has no runtime surface to verify?

Report SKIP with a one-line reason. Docs-only changes, type declarations with no emit, and tests-only PRs have nothing to run, so there is no behavioral verification to perform.

When should a verification result be FAIL instead of PASS?

FAIL when the app runs but the change does not work, breaks something else, or the claim and diff materially disagree. Ambiguous output is also FAIL with the raw capture attached, since a false PASS ships broken code.