Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →brycewang-stanford/cvpr-reproducibility
Use when hardening a CVPR paper's reproducibility story, covering the Compute Reporting Form's hardware and compute sections, training-recipe disclosure, benchmark protocol and split hygiene, seed and variance reporting for vision experiments, and closing the gaps reviewers probe at a benchmark-driven venue.
Passed 19 of 22 test cases with the skill, and 14 of 22 without it.
and 7 more in the full report
5 fixed14 passed either way3 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
Please perform a thorough reproducibility audit on our CVPR paper draft and experimental ledger. I need a review that details our overall reproducibility grade, checks hardware consistency between the manuscript and compute reporting declarations, lists the fraction of table rows covered by complete recipes, assesses benchmark hygiene regarding dataset splits, metric provenance, test run frequency, and pretraining details, breaks down multi-seed vs single-run experiments, and provides a prioritized list of fixes ordered by potential reviewer impact.
| Checked | Without skill | With skill |
|---|---|---|
| Output starts with the header [Repro grade]. | Missed | Passed |
| Output contains the section header [CRF]. | Missed | Passed |
| Output contains the section header [Ledger]. | Missed | Passed |
The instructions your model reads when the skill loads.
At CVPR, reproducibility failures rarely look like fraud; they look like a table nobody can match because one augmentation flag, one crop size, or one pretraining corpus went unstated. This skill hardens the paper against that fate, anchored in the 2026-cycle machinery (checked 2026-07-08): the Compute Reporting Form, the anonymous supplement, and reviewers trained on a decade of un-reproducible state-of-the-art claims.
The 2026 cycle attached a Compute Reporting Form to every submission — Section 1 (hardware specification) and Section 5 (verification) mandatory, deeper sections optional, with an explicit opt-out route for proprietary constraints. Treat the mandatory floor as the start, not the ceiling:
| CRF layer | What it pins down | Why reviewers care |
|---|---|---|
| Hardware (mandatory) | GPU model, count, primary configuration | Grounds every "real-time" and "efficient" claim |
| Verification (mandatory) | Author attestation | Somebody owns the numbers |
| Task/compute (optional) | GPU-hours or FLOPs per result | Separates a 4-GPU method from a 512-GPU method |
| Full logs (optional) | Run-level records | The strongest possible "we actually ran this" |
If your contribution is efficiency, filling only the mandatory sections undercuts your own claim — report the compute and let the numbers argue.
Vision results are recipe-sensitive. Maintain one machine-readable ledger from the first experiment, and generate the paper's implementation-details paragraph from it instead of reconstructing details in deadline week:
# recipe-ledger.yaml — one block per reported table row
table3_row2:
backbone: vit-b16, pretrain: <corpus + checkpoint hash>
data: <dataset version + split file sha256>
aug: [rrc-224, hflip, randaug-m9]
optim: adamw, lr: 1.0e-4, sched: cosine, epochs: 90, batch: 1024
seed: 3407 # and whether cudnn deterministic was set
hardware: 8xA100-80G # must agree with CRF Section 1
test cases passed, vs 14 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.