mobicom-artifact-evaluation
Use when packaging a MobiCom artifact for the evaluation committee — choosing among the three ACM badges as a calibration of what you can prove, building a hardware-optional reproduction path for evaluators without radios, writing the smoke run that establishes functionality, and making code, data, and traces available.
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mobicom-artifact-evaluation --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.
# MobiCom Artifact Evaluation MobiCom accepted papers may earn the three **ACM badges** — *Artifacts Available*, *Artifacts Evaluated — Functional*, and *Results Reproduced* — from a separate artifact-evaluation committee (AEC). The badges are independent: you may pursue one, some, or all. The engineering problem specific to MobiCom is that the evaluation depends on a **radio testbed the AEC does not have**, so the packaging must let an evaluator get as far as possible without one. ## Choose badges as a claim of what you can prove | Badge | What it asserts | What the AEC needs | |---|---|---| | Artifacts Available | the artifact is publicly and permanently retrievable | a stable public archive (DOI-backed) | | Artifacts Evaluated — Functional | the artifact runs and does what the paper describes | a working build + smoke run on reachable hardware | | Results Reproduced | the paper's key results regenerate | a path from artifact to the headline numbers | Pick badges honestly. *Available* is almost always worth claiming and is the lowest-friction. *Functional* requires a path that runs without your specific radios. *Results Reproduced* is hardest for a wireless paper because the chan
- Choose badges as a claim of what you can prove
- The hardware-optional path is the core deliverable
- Make availability real
- Document variance honestly
- Pre-submission checklist
- Output format
What does the mobicom-artifact-evaluation skill do?
Use when packaging a MobiCom artifact for the evaluation committee — choosing among the three ACM badges as a calibration of what you can prove, building a hardware-optional reproduction path for evaluators without radios, writing the smoke run that establishes functionality, and making code, data, and traces available.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill mobicom-artifact-evaluation --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.