uist-reproducibility
Use when making a UIST paper's results replicable — reporting implementation parameters and measurement protocols so a lab could rebuild the system, specifying hardware down to parts and calibration, logging technical evaluations deterministically, and writing honest availability statements for interface systems.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill uist-reproducibility --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# UIST Reproducibility Reproducibility at UIST means something different from rerunning a training script: the question is whether a competent lab could **rebuild the artifact and reproduce its measured behavior**. That decomposes into three ledgers — build, measurement, and study — and most UIST papers under-specify a different one than they think. UIST posts no reproducibility checklist (none found for 2026 — 待核实), so this discipline is self-imposed and reviewer-enforced. ## The build ledger: could they make one? Everything the system's behavior depends on, pinned: - **Software**: exact framework and driver versions, OS, lockfiles; for anything learned, model checkpoints and training data provenance. - **Hardware**: part numbers (not "an IMU" but which IMU), mechanical tolerances that matter, firmware version, and the calibration routine with expected outputs. - **Environment**: the physical conditions the system assumes — lighting range, acoustic environment, mounting geometry, surface materials. - **Magic numbers**: every threshold, filter coefficient, debounce window, and gain, with how each was set (tuned by hand? on which data?). These constants are where re-implementations
- The build ledger: could they make one?
- The measurement ledger: could they get your numbers?
- The study ledger: could they rerun the human part?
- The availability statement
- Learned components inherit ML norms
- The one-page REPRO.md
- Replication drift and its uses
- Output format
eval/rerun.sh — regenerate every reported number from raw logs python analyze_latency.py logs/latency_10k.jsonl --out tables/table1.csv python analyze_accuracy.py logs/study/ --split per-user --seed 17 --out tables/table2.csv diff -u tables/table1.csv paper_tables/table1.csv # drift check against the PDF
What does the uist-reproducibility skill do?
Use when making a UIST paper's results replicable — reporting implementation parameters and measurement protocols so a lab could rebuild the system, specifying hardware down to parts and calibration, logging technical evaluations deterministically, and writing honest availability statements for interface systems.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill uist-reproducibility --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From brycewang-stanford/Awesome-Journal-Skills, a repository with 909 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.