agentsclimarketplace

Sensys topic selection

Skill brycewang-stanford/Awesome-Journal-Skills/SenSys-Skills/skills/sensys-topic-selection

Use when deciding whether a project belongs at SenSys after the 2026 merger absorbed IPSN and IoTDI — testing whether the contribution is a built, measured sensing/embedded/IoT/on-device-AI system rather than a pure algorithm, a mobile-networking mechanism, or an offline ML result, and routing misfits to MobiCom, MobiSys, or an ML/DSP venue.From its SKILL.md

Install
npx -y skills add brycewang-stanford/Awesome-Journal-Skills --skill sensys-topic-selection

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

SKILL.md

5.2 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

SenSys Topic Selection

SenSys accepts a system you built and measured under embedded constraints. The 2026 merger of SenSys, IPSN, and IoTDI widened the mandate — low-power networked sensing, embedded systems, IoT, and on-device AI now share one venue — but it did not soften the systems bar: a strong SenSys paper still has a buildable mechanism whose value is shown in energy, latency, memory, and deployment behavior on real hardware, not in a proof or a leaderboard delta.

The fit test

Ask these in order; a "no" is a routing signal, not a verdict on the work's quality.

  1. Is there a system? Can you point to the artifact — firmware, a node, a protocol, a deployment — that embodies the contribution? A pure algorithm with no embedded realization is a signal-processing or ML contribution.
  2. Do embedded constraints bind? Does energy, memory, compute, bandwidth, or intermittent power actually shape the design? If the method would run unchanged on a workstation, the constraint is not doing work and SenSys is a weak fit.
  3. Is the evidence physical? Are the headline numbers measured on hardware — current draw, duty cycle, on-device latency, deployment uptime — or are they simulation/offline accuracy? SenSys reviewers discount simulation-only and single-run results.
  4. Is sensing or embedded computation central? SenSys is about turning physical signals into information under resource limits, or computing on constrained nodes — not about the wireless link itself (that is MobiCom) or the mobile application platform (that is MobiSys).

Routing table

If the core contribution is...The likely home is...Because
A built sensing system measured on real hardware for energy/latency/accuracySenSysThe merged venue's center of mass
Low-power networked sensing / mote-class protocols (formerly IPSN)SenSys (post-merger)IPSN's community joined SenSys in 2026
IoT design/implementation, edge deployments (formerly IoTDI)SenSys (post-merger)IoTDI's community joined SenSys in 2026
An on-device / TinyML model with measured footprint on an MCUSenSysEmbedded-AI systems are in-scope after the merger
A wireless link, PHY/MAC, or over-the-air networking mechanismMobiComThe mechanism is the radio, not the sensing system
A mobile-platform / smartphone systems contributionMobiSysThe platform, not embedded sensing under energy limits
A new estimator/algorithm with no embedded realizationan ML or DSP venueThe contribution is the math, not a built system
A datacenter/OS/networking systems resultNSDI / OSDI / SIGCOMMNot sensing/embedded and not energy-bound

Post-merger boundary calls

The merger creates new adjacencies to reason about explicitly:

  • On-device AI vs. an ML paper. If the novelty is model architecture or accuracy, it is an ML venue. If the novelty is running inference within a real MCU's RAM/flash/energy budget — quantization-for-hardware, intermittent-power inference, on-sensor compute — it is SenSys.
  • IoT deployment vs. an applications paper. A deployment is SenSys when the system design or measurement methodology is the contribution, not merely that a known stack was installed.
  • Sensing vs. signal processing. A new algorithm belongs at a DSP venue unless it is embodied and measured on the constrained node where it must actually run.
Fit self-check (answer before choosing SenSys):
[ ] There is a concrete built system/artifact, not only a method.
[ ] An embedded constraint (energy/memory/compute/power) shapes the design.
[ ] Headline numbers are measured on real hardware, not simulation-only.
[ ] Sensing or on-node computation — not the radio or the app platform — is central.
[ ] If on-device AI: the claim is measured footprint/latency, not offline accuracy.

When two venues both fit

Some work genuinely spans SenSys and MobiCom (e.g. a sensing system that also innovates on its link). Route by where the reviewable novelty lives: if a reviewer would spend most of their judgment on the sensing/embedded system and its energy behavior, submit to SenSys and treat the link as engineering; if the defensible novelty is the wireless mechanism, submit to MobiCom. Pick one — a paper straddling both usually reads as under-contributing to each.

Output format

[Verdict]  SenSys fit: strong / plausible / weak
[System]   the concrete artifact that embodies the contribution
[Constraint] which embedded limit binds the design (energy/memory/compute/power)
[Evidence] hardware-measured? or simulation/offline (a re-route risk)
[Reroute]  if weak — target venue + the one sentence that would move it
[Open]     any post-merger boundary ambiguity to resolve before committing

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.