Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →brycewang-stanford/cav-artifact-evaluation
Use when packaging a CAV (Computer Aided Verification) artifact for the Artifact Evaluation Committee (AEC), covering the three badges (Available / Functional / Reusable), the smoke-test and full-review phases, ≥2 AEC reviewers per artifact, DOI-issuing archives, verification-tool packaging (solvers, benchmarks, seeds, resource limits, proof witnesses), and the fact that AE is invited, post-notification, and non-conditional.
Passed 22 of 24 test cases with the skill, and 20 of 24 without it.
3 fixed19 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are packaging a software model checker for CAV artifact submission. We included clean build scripts, an Apache 2.0 license, benchmark scripts, and an explicit mapping table. However, we plan to host the artifact solely on a public GitHub release tag rather than Zenodo or Figshare because GitHub is permanent enough for us. Can we qualify for the Reusable badge with this setup? Give us a complete artifact evaluation report.
| Checked | Without skill | With skill |
|---|---|---|
| The response states that the Reusable badge requires the Available badge | Missed | Passed |
The instructions your model reads when the skill loads.
Use this for the artifact track. CAV artifact evaluation is run by a dedicated Artifact Evaluation Committee (AEC), is invited but optional after notification, and — importantly — final paper acceptance is not conditional on it. Authors declare artifact intent at submission time; the actual AEC submission comes after acceptance, on the artifact track's own deadline (CAV 2026 artifact registration: 22 Apr 2026). Two things to internalize: badges are earned by AEC members actually running your package, and for anonymized paper categories the review-time material and the AEC artifact are handled differently (the AEC artifact is post-notification, so de-anonymization is fine).
| Badge | What it certifies | What earns it |
|---|---|---|
| Available | The artifact is permanently, publicly retrievable | Deposit in a DOI-issuing archival repository (Zenodo, figshare, Software Heritage) |
| Functional | The artifact is documented, consistent, complete, and exercisable | A clean-machine install, a working run, and documented expected outputs |
| Reusable | Quality significantly exceeds Functional; others can build on it | Functional plus a reuse license, clear structure, and easy-to-adapt docs; requires Available |
Available is a low-cost, high-value badge (archive the package with a DOI). Functional and Reusable require the AEC's own run to succeed, so the failure mode is almost always "it did not build/run on their machine," not "the idea was weak." Reusable additionally requires that the artifact already be Available.
Each artifact is examined by at least two AEC members across two phases:
[Smoke-test phase] reviewers confirm the artifact downloads, unpacks, and the basic entry point
runs on a clean environment. Fix any friction here and you can still respond.
[Full-review phase] reviewers work through the claims: run the tool on the benchmarks, check the
documented outputs, and assess reusability for the Reusable badge.
Design so the smoke test succeeds in the first ten minutes on a fresh machine — a VM image or a container removes most smoke-test failures.
| Claim type | First thing inspected | Common failure caught |
test cases passed, vs 20 / 24 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.