Skip to content
Back to skills

Mobicom Artifact Evaluation

ASecurity

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.

  • 3 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 12, 2026
ai-agentsgogit

Security analysis

A100/100

Scanned September 12, 2026

npx -y skills add thedixitjain/the-mega-skill-library --skill mobicom-artifact-evaluation --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Mobicom Artifact Evaluation?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Mobicom Artifact Evaluation
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/thedixitjain-mobicom-artifact-evaluation/badge)](https://www.skillsdirectory.com/skills/thedixitjain-mobicom-artifact-evaluation)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: mobicom-artifact-evaluation
description: "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."
category: data-science-and-ml
source_repo: brycewang-stanford/Awesome-Journal-Skills
source_path: "MobiCom-Skills/skills/mobicom-artifact-evaluation/SKILL.md"
source_url: https://github.com/brycewang-stanford/Awesome-Journal-Skills/blob/HEAD/MobiCom-Skills/skills/mobicom-artifact-evaluation/SKILL.md
---


# 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 channel is not portable — claim it only where a
trace-replay or downscaled path can regenerate the numbers (`mobicom-reproducibility`). The
exact 2027 badge deadlines and process are 待核实 — read the current artifact call.

## The hardware-optional path is the core deliverable

Most AEC members will not have your SDRs, tags, or testbed. Design the package so a reviewer
without hardware still reaches *Functional*:

```text
artifact/
  README            # claims, badge targets, hardware needed vs optional, time budget
  env/              # container or pinned deps; no radio required to build
  smoke/            # runs in ~minutes on a laptop, no radio; proves the pipeline
  replay/           # recorded captures + decode/analysis -> regenerates key figures
  hardware/         # optional: scripts + exact radio/firmware to reproduce on a testbed
  data/             # traces that can legally ship (or a loader + instructions)
  expected/         # expected outputs AND expected variance ranges
```

- The **smoke run** is the functionality proof: a short, laptop-only command that exercises
  the pipeline end-to-end on bundled data and prints a recognizable result.
- The **replay path** feeds recorded captures through the same processing that produced the
  paper's figures, so results regenerate without the radio.
- The **hardware path** is documented for the rare evaluator (or future reader) with a
  matching testbed, with exact radio model, firmware, and channel setup.

## Make availability real

- Deposit in a **permanent, DOI-backed archive**, not a personal URL that rots.
- Confirm what can legally ship: firmware and proprietary radio stacks often cannot;
  user-identifiable captures must be stripped or aggregated; site data may be bound by an
  agreement (`mobicom-reproducibility`).
- If part of the artifact cannot be released, say so explicitly and ship the largest
  functional subset rather than a broken whole.

## Document variance honestly

An over-the-air result differs run to run. Ship **expected-variance** files alongside
expected outputs so a rerun that lands within a stated margin reads as a reproduction, not a
failure. An AEC member who sees a number move and has no variance guidance will log it as a
non-reproduction.

## Pre-submission checklist

- [ ] Badge targets chosen to match what the package can actually prove.
- [ ] Smoke run works on a clean laptop with no radio, in a stated time budget.
- [ ] Replay path regenerates the key figures from bundled captures.
- [ ] Hardware path documents exact radio/firmware/channel for testbed reproduction.
- [ ] Available artifact is in a permanent DOI-backed archive.
- [ ] Legal/ethical shipping decision made for firmware, traces, and site data.
- [ ] Expected outputs and expected variance both provided.

## Output format

```text
[Badges] targeted vs justified by the package
[Smoke] laptop-only run present + time budget
[Replay] key figures regenerate without hardware? y/n
[Hardware path] radio/firmware/channel documented? y/n
[Availability] archive + DOI + legal-shipping decision
[Gaps] what blocks each targeted badge
```

---

**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `MobiCom-Skills/skills/mobicom-artifact-evaluation/SKILL.md`

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.