MobiSys Skills

A 12-skill depth pack for ACM MobiSys submissions: mobile-systems topic fit, HotCRP submission audit, the two-round + rebuttal response, ACM-badge artifact evaluation, on-device reproducibility, supplementary packaging, review-process modeling, 12-page writing, related-work coverage, real-device experiments, workflow, and sibling routing. Grounded in the official MobiSys 2026 CFP, artifact-evaluat

by @brycewang-stanford 12 skills

Install

npx skillmds@latest add plugin:brycewang-stanford/mobisys-skills

One command, no setup. In Claude Code it lands as a managed plugin you can enable, disable or remove with /plugin. On any other agent it installs the 12 skills into that agent's own folder.

Or inside Claude Code

In the Plugins tab, add this marketplace:

skillmds/skillmd
/plugin install brycewang-stanford-mobisys-skills@skillmd

Adds the marketplace once; later plugins need the second line only.

Or install by hand

Download the plugin and unzip its skills/ folder into your agent's skills directory. Works with every agent, no CLI needed.

Download plugin Paths per agent

Just the markdown? SKILL.md files only.

This plugin

skills: 12
authors: 1

Published by a registry member. Review its skills before installing.

Skills in this plugin

▌
Mobisys Workflow · brycewang-stanford
Use when planning a MobiSys project timeline backward from the single early-December paper deadline through registration, two-round review with an early-reject cut, the rebuttal, notification, artifact evaluation, camera-ready, and the June conference — with device-experiment lead time built in and the one-deadline-per-year risk made explicit.

1k repo stars
▌
Mobisys Submission · brycewang-stanford
Use when auditing a MobiSys submission for HotCRP readiness — the paper-registration prerequisite, the single December UTC deadline, the 12-page double-column body including figures and tables, double-blind anonymity including device and trace giveaways, desk-reject triggers, and final-week submission sequencing.

1k repo stars
▌
Mobisys Experiments · brycewang-stanford
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.

1k repo stars
▌
Mobisys Camera Ready · brycewang-stanford
Use when preparing an accepted MobiSys paper for the ACM Digital Library camera-ready — de-anonymization, the ACM double-column final layout and 12-page budget, ACM rights and CCS metadata, delivering any results promised in the rebuttal, coordinating the three artifact badges, registration, and the June in-person talk and demo in Cambridge.

1k repo stars
▌
Mobisys Related Work · brycewang-stanford
Use when positioning a MobiSys submission against the mobile-systems literature — offload, on-device ML, mobile OS and runtimes, sensing services, and energy — covering the right lanes, handling concurrent work, verifying that cited "MobiSys papers" are MobiSys rather than MobiCom/SenSys/OSDI, and self-citing without breaking double-blind.

1k repo stars
▌
Mobisys Supplementary · brycewang-stanford
Use when preparing MobiSys supplementary material — appendices, extra device sweeps, protocol details, demo video and media, and anonymized artifacts under the 12-page-body, double-blind, and reviewer-discretion constraints, including how to split a mobile-systems paper between body, references-and-appendix overflow, and HotCRP fields.

1k repo stars
▌
Mobisys Writing Style · brycewang-stanford
Use when revising a MobiSys paper for a mobile-systems first page, the pain → system-design → on-device-evidence arc, 12-page double-column compression, double-blind wording, and claims disciplined by measured latency, energy, memory, and thermal budgets rather than superlatives, so the draft survives systems-and-services reviewers.

1k repo stars
▌
Mobisys Review Process · brycewang-stanford
Use when explaining or planning around MobiSys peer review — the two-round process with an early-reject cut after round 1, the round-2 rebuttal window, double-blind HotCRP mechanics, the systems-and-services reviewer pool, and decision criteria for on-device claims, so response strategy fits how MobiSys decides.

1k repo stars
▌
Mobisys Author Response · brycewang-stanford
Use when drafting a MobiSys rebuttal after round-2 reviews — working within the scope limit (correct factual errors, answer specific reviewer questions), adding only directly-responsive new results, promising camera-ready work honestly, staying double-blind, and giving the area chair a clean rationale for a mobile-systems accept decision.

1k repo stars
▌
Mobisys Reproducibility · brycewang-stanford
Use when strengthening MobiSys reproducibility evidence — capturing device, SoC, OS build, framework and model versions, power-instrument setup, seeds, and thermal conditions so an on-device result survives a different phone, deciding what data and firmware can legally ship, and keeping the paper consistent with the artifact for the ACM badge pipeline.

1k repo stars
▌
Mobisys Topic Selection · brycewang-stanford
Use when deciding whether a project belongs at MobiSys — testing whether the core contribution is a mobile or embedded system, application, or service whose on-device behavior is the result, and routing wireless, sensor-network, distributed-systems, ubicomp, or early-idea misfits to MobiCom, SenSys, NSDI/OSDI, IMWUT, or HotMobile.

1k repo stars
▌
Mobisys Artifact Evaluation · brycewang-stanford
Use when packaging a MobiSys artifact for the Artifact Evaluation Committee — choosing among the three independent ACM badges (Available, Evaluated–Functional, Results Reproduced), building the workflow scripts the single-blind AEC runs on its own machines, and providing a hardware-optional path for evaluators who lack the exact phone, wearable, or board.

1k repo stars