Verify
Prove a change works end to end through acceptance criteria, focused project gates, real user or caller flows, edge cases, and reliability checks. Use before a PR, when the user asks whether a change actually works, or as the first stage of $ship even when automated tests are green.From its SKILL.md
npx -y skills add magarcia/skills --skill verifyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 18 days oldThe repository was created 18 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.6 KB, 438 tokens by cl100k_base, as published. Nobody here has run it
Verify
Read every applicable AGENTS.md before choosing commands or environments.
- Acceptance criteria — Re-read the request or ticket and write down the observable behaviors required. If they cannot be stated without a material product decision, ask for that decision.
- Existing gates — Discover the repository's commands. Start with the smallest relevant tests, typecheck, lint, diagnostics, and build checks for the changed code. Expand to broader suites when repository convention, change risk, or the user's request requires them. A relevant regression blocks verification; label unrelated pre-existing failures separately.
- Drive it end to end — Exercise the public interface as a user or caller would:
- UI: use
$agent-browserfor the real flow and screenshots unless project instructions mandate another runner. Load its current core workflow before browser commands. - API: send real requests to a local or designated test environment, cover success and error paths, and inspect responses and test-state persistence.
- CLI: run the command through its public entry point with valid and invalid input.
- Library: consume the public API from a focused scratch or existing integration test. Use repository verification scripts, seed data, and QA documentation when available.
- UI: use
- Sweep edge cases — For each touched input or state, consider empty, null, zero, boundaries, duplicates, double-submit or retry, dependency failure, and wrong permissions. Establish the expected outcome and add tests for credible regression risks.
- Check reliability — Determine what happens if work is interrupted, whether production errors are diagnosable, whether new external calls have bounded timeouts and retries, and whether migrations have a documented recovery path. Inspect these properties; do not perform destructive recovery tests without explicit authorization.
Do not send mutating requests to production or another external system unless the user explicitly authorized that exact target and action. If credentials or the environment prevent a check, state precisely what remains unverified instead of reducing the claim to "tests pass."
Report broken behavior first, then acceptance-criteria pass or fail with evidence, edge-case outcomes, relevant command results, screenshots, and remaining risk.
What ships with it: 1 file
205 B alongside SKILL.md
agents/
- openai.yaml205 B