Use when designing or auditing the evaluation of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — matching evidence to the claim with real testbeds, fair baselines, end-to-end plus microbenchmark results, tail-latency and variance reporting, workload realism, and honest cost accounting.
SkillScore95Maintained
Automatic
◆Research pack
Last verified 8/15/2026
What it changes
Passed 21 of 22 test cases with the skill, and 16 of 22 without it.
Without skill73%
With skill95%
Checks it passed that the model alone missed
Contains '[Depth]'
Contains '[Testbed]'
Contains '[Honesty]'
and 13 more in the full report
5 fixed16 passed either way1 still failing0 broke
Pass-rate lift
+23 pp
Tokens
+24%
Agent turns
0%
Response time
-30%
Model gemini-3.6-flashMeasured 8/15/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
We are archiving experimental metadata right before paper submission. We recorded CPU models, OS kernel version, compiler version, and benchmark scripts. What crucial code tracking element must be pinned?
What was checked, without and with the skill
Checked
Without skill
With skill
Requires pinning commit SHAs for both the evaluated system and all baselines
Missed
Passed
case-16 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md89 linessingle file
ATC Experiments
Match the evidence to the claim. ATC is the systems community's implementation-and-measurement
venue: reviewers read for measured behavior on a real system, not asymptotics or accuracy on a
dataset. In round two, 3-4 reviewers close to your subarea will open the artifact and probe whether
the numbers are end-to-end, fair, and honest about cost. Design the evaluation so their first three
objections are already answered.
Match evidence to claim shape
If your claim is...
The evidence ATC expects
"Faster / lower latency"
End-to-end latency including tails (p99/p999) and throughput at a matched operating point, on a described testbed
"Lower overhead / cheaper"
The resource cost (CPU, memory, writes, energy) measured, at matched function — not just the headline win
"Scales"
Measurements across a real range of load/nodes/cores with the scaling curve and where it bends
"More reliable / correct"
Fault-injection or crash/recovery experiments, not just steady-state runs
"Useful in practice" (experience)
Production-derived workloads and lessons; what broke and what generalizes
Real testbeds and workloads
Describe the testbed so results are reproducible: CPU/NIC/SSD models, core counts, memory,
kernel/OS versions, network topology, and any co-location. A result without its testbed is not a
systems result.
Use realistic workloads. Production-derived traces, standard benchmarks, or documented
generators beat hand-picked inputs. State how the workload was obtained and why it is
representative; if it is synthetic, justify the parameters.
Warm-up and steady state. Say how you handled cold start, warm-up windows, and measurement
duration — systems reviewers know where transient effects hide.
Fair baselines
Compare against the strongest reasonable alternative, configured well (a strawman baseline is
caught immediately). If you tuned your system, tune the baseline.
Compare at a matched cost or operating point: same memory budget, same flash-write budget,
same load. An unmatched comparison is the classic systems-reviewer objection.
If no baseline exists, say so and use the unmodified system or an ablation of your own design
as the reference.
Use when drafting or revising an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — writing a self-standing two-page extended abstract for the round-one gate, structuring the implementation-and-measurement narrative, reporting costs beside gains, and holding the two-column 12-page budget.