mobisys-experiments
Use when designing or auditing the evaluation of a MobiSys submission — building real-device testbeds, instrumenting energy and thermal behavior, measuring latency and frame-rate tails, bounding memory footprint, choosing tuned system baselines, and running deployments or user studies, so systems reviewers see where the system wins and breaks on the device.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mobisys-experiments --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.
# MobiSys Experiments A MobiSys result becomes believable only when it is **measured on real hardware, driven to steady state, and reported in latency, energy, memory, and thermal terms**. Simulation-only or single-run numbers read as under-done. The evaluation axis here is the *device and platform* — compute, energy, latency, memory, heat — not the radio or channel a wireless venue grades, and not the traffic-and-topology an infrastructure venue grades. Build the evaluation as one device-behavior claim per experiment. ## Turn each claim into one device experiment The clean structure gives each subsection a claim about the running system, then the one experiment that settles it. The opposite habit — run a benchmark suite and describe whatever survives — is the unfocused evaluation MobiSys reviewers push back on. The claim-to-experiment map for a running mobile system: | Claim about the system | Experiment that settles it | Metrics | |---|---|---| | It meets the target in the motivating scenario | on-device run under the real workload | p50/p95 latency, throughput, task success | | Its energy cost is acceptable | instrumented run on a power monitor | energy-per-operation, average an
- Turn each claim into one device experiment
- What the setup must state
- Making energy and heat auditable
- Comparators a systems reviewer will trust
- Report the spread, never a lone peak
- Pre-submission evaluation pass
- Output format
What does the mobisys-experiments skill do?
Use when designing or auditing the evaluation of a MobiSys submission — building real-device testbeds, instrumenting energy and thermal behavior, measuring latency and frame-rate tails, bounding memory footprint, choosing tuned system baselines, and running deployments or user studies, so systems reviewers see where the system wins and breaks on the device.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mobisys-experiments --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.