Claude Skills by brycewang-stanford

Use when reasoning about how a MICRO submission is judged — the double-blind HotCRP pipeline from the April deadline through the June rebuttal/revision window to the early-July notification, what reviewers score in a microarchitecture paper, the professional-conduct rules, and how the new Industry Track review differs.

Use when auditing a MICRO submission before HotCRP upload — the 11-page-plus-references limit with no appendix allowed, EDT (not AoE) deadline arithmetic, the abstract-registration gate a week before the paper, minimum 9pt fonts, mandatory page numbers, all-author reference entries, and MICRO's visual-plus-automated format inspection.

Use when deciding where a MICRO paper's supporting material lives, because MICRO allows no appendix at all — triaging content into the 11 reviewed pages, the unlimited references, an anonymized artifact repository, or the post-acceptance two-page artifact appendix, and cutting what fits nowhere.

Use when deciding whether a project belongs at MICRO (IEEE/ACM International Symposium on Microarchitecture) or should route to ISCA, HPCA, ASPLOS, DAC/ICCAD, SC, or MLSys — testing whether the mechanism truly lives inside the machine, gauging the MICRO evidence bar, and weighing the main track against the new Industry Track.

Use when planning a MICRO campaign end to end — the April-to-Athens 2026 cycle clock, the four-venue architecture calendar (MICRO/ISCA/HPCA/ASPLOS) seen from MICRO's October seat, resubmission lattices after each outcome, and starting the MICRO 2027 evaluation stack early enough to matter.

Use when drafting or revising a MICRO paper's prose and structure — building the characterization-motivated introduction, budgeting 11 appendix-free pages, drawing the mechanism walkthrough a microarchitect can re-implement, and pairing every speedup claim with its area, storage, and power cost line.

Use when packaging an accepted MLSys paper's code, configs, and measurement scripts for the venue's post-acceptance artifact evaluation, targeting the Availability, Functional, and Reproducible badges, writing the Artifact Appendix, handling hardware that AE reviewers cannot access, and answering anonymous evaluator questions.

Use when drafting MLSys author responses on OpenReview under the venue's compressed rebuttal window, prioritizing systems-reviewer objections about workload representativeness, baseline tuning, and missing measurements, deciding whether to run new experiments in days, and keeping replies anonymous and decision-focused.

Use when preparing an accepted MLSys paper for publication on proceedings.mlsys.org, covering de-anonymization of the research-track PDF, restoring company and repository identity, reconciling promised rebuttal edits, the reserved-ticket registration window for authors, and sequencing camera-ready work against the artifact-evaluation deadline.

Use when designing or auditing the evaluation of an MLSys paper, selecting representative workloads and hardware, tuning baselines symmetrically, reporting throughput, latency tails, memory, cost, and quality together, structuring ablations that attribute gains to mechanisms, and building scaling and sensitivity evidence reviewers trust.

Use when positioning an MLSys submission against the fast-moving ML-systems literature scattered across OSDI, SOSP, NSDI, ASPLOS, and ML venues, handling arXiv-first and open-source-first prior work, comparing against production systems that have no paper, and writing the delta statement two reviewer cultures will both accept.

Use when hardening the reproducibility of MLSys performance claims, pinning the full system layer from driver to interconnect, separating ML randomness from systems noise, choosing repetition counts and variance reporting for throughput and latency numbers, and disclosing hardware, workloads, and cost so strangers can re-measure results.

Use when reasoning about how MLSys peer review works, covering the OpenReview workflow, the mixed ML-and-systems reviewer pool and how each half scores differently, the compressed response window, industrial-track review expectations, decision dynamics, and what the post-acceptance artifact stage means for review strategy.

Use when auditing an MLSys submission for OpenReview readiness, covering the two-column 10-page body excluding references, the separate appendix upload, double-blind rules that still permit arXiv posting, research-versus-industrial track requirements, dual-submission exceptions, style-kit compliance, and desk-reject triage before the deadline.

Use when deciding what goes into an MLSys appendix versus the 10-page body, exploiting the venue's unlimited separately-uploaded appendix that reviewers are not required to read, organizing configs, traces, extended results, and anonymized code pointers, and keeping supplementary material blinded for the research track.

Use when deciding whether a project belongs at MLSys rather than OSDI, SOSP, NSDI, ASPLOS, ATC, EuroSys, or the ML conferences, testing for genuine ML-systems co-design, choosing between the research and industrial tracks, and sharpening the systems-for-ML or ML-for-systems framing before writing starts.

Use when planning an MLSys submission cycle end to end, from venue-fit and track choice through evaluation freeze, the October deadline, the four-day January response, notification, camera-ready, the March artifact-evaluation submission, and the May conference, with backward planning built around scarce GPU time and team ownership.

Use when revising an MLSys paper's prose and structure, building the measured-bottleneck opening, naming the mechanism instead of listing optimizations, writing evaluation sections as answers to research questions, quantifying every performance claim with workload context, and fitting the argument into the venue's 10-page two-column body.

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.

Use when writing a MobiCom rebuttal after round-two reviews or executing a one-shot revision — triaging reviewer points by severity, fitting a factual, concession-honest rebuttal into its length limit, and turning a required-changes list into a change-highlighted revision with a change summary that the same reviewers can verify.

Use when preparing an accepted MobiCom paper for publication — de-anonymizing into the double-column final version, discharging every rebuttal and revision promise, completing ACM rights and metadata, coordinating the artifact-badge timeline, and planning the in-person presentation for the Austin program.

Use when designing or auditing the evaluation of a MobiCom submission — building real-device testbeds, choosing RF and channel measurement methodology, injecting realistic mobility and interference, profiling energy on hardware, picking tuned baselines, and reporting distributions so wireless reviewers see where the mechanism wins and breaks.

Use when building or auditing the related-work of a MobiCom paper — sweeping the SIGMOBILE and networking literature lanes, proving each citation's venue on dblp/ACM DL against the INFOCOM/SIGCOMM/NSDI misattribution traps, positioning against the current rolling-cohort cohort, and self-citing without breaking double-blind.

Use when making a MobiCom result reproducible on a different testbed — recording radio, hardware, channel, and mobility provenance as the runs happen, characterizing the variance that over-the-air measurement introduces, and deciding early which traces, firmware, and deployment data can legally and safely ship for artifact evaluation.

Use when reasoning about where a MobiCom paper sits in the two-round review process — the early-reject cut after round one, the released reviews and rebuttal window after round two, the accept / one-shot revision / reject outcome space, reviewer continuity across a revision, and how the rolling-deadline structure shapes what to do next.

Use when running the final pre-upload audit of a MobiCom submission — confirming the right per-edition HotCRP site and round, the AoE cutoff printed as an Eastern clock time, the 12-page double-column cap, the abstract-registration prerequisite, and the double-blind sweep including wireless-testbed identity leaks.

Use when deciding what goes in the MobiCom 12-page double-column body versus references, optional appendices, and HotCRP fields — placing channel-model derivations, full protocols, and extended measurements outside the cap, keeping the contribution self-contained, and ensuring rebuttal and revision packets stay off the page count.

Use when deciding whether a project belongs at MobiCom or a sibling venue — testing whether the core contribution is a mobile/wireless-networking mechanism the SIGMOBILE flagship rewards, and routing platform, sensing, broad-networking, security, or ubicomp misfits to MobiSys, SenSys, SIGCOMM/NSDI, WiSec, or IMWUT before a cycle is committed.

Use when planning a MobiCom campaign across the rolling two-deadlines-per-year calendar — deciding which round to target and which edition it feeds, building a backward schedule that leaves room for over-the-air experiments, and sequencing the two-round review, rebuttal, and one-shot revision so a slip does not silently cost an edition.

Use when drafting or revising a MobiCom paper for house style — putting the wireless/mobile mechanism and its operating regime on the first page, pairing every claim with over-the-air measurement, replacing superlatives with percentiles and intervals, and fitting the argument into the double-column 12-page body.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Use to convert references to the current Cell Press numbered style used by Molecular Cell — superscript numbers in order of first appearance, a reference list numbered in that order, full author lists (no et al.), abbreviated journal names. This is NOT author-date; older Cell Press author-date manuscripts must be renumbered.

Use to build Molecular Cell's data and code deposition plan and the Data and Code Availability statement inside STAR Methods Resource Availability — approved repositories (GEO, PDB/EMDB, PRIDE), accessions/DOIs at submission, and Cell Press's standardized availability format with Mendeley Data as Elsevier's default.

Use to finalize Molecular Cell display items — column-width sizing, minimum fonts, RGB, show-the-data with defined error bars/n/replicate type, gel/blot and structural-figure integrity, colorblind-safe palettes, multi-panel discipline, and stand-alone legends built for a mechanism proof.

Use when triaging a study before any writing — stress-tests whether it clears Molecular Cell's bar (a deep molecular mechanism proven by orthogonal approaches with physiological relevance) or belongs at a sibling. Use this first to decide Molecular Cell vs Cell vs Cell Reports vs NSMB/EMBO J before investing in framing or figures.

Use to lock the single-mechanism arc before drafting — converts a set of correct experiments into one Molecular Cell story that runs molecular question → the mechanism → physiological consequence, not a catalog of techniques.

Use to produce the three signature Cell Press front-matter artifacts for Molecular Cell — Highlights (3–4 bullets, each ≤85 characters), the eTOC/In Brief blurb (~50 words, third-person), and the Graphical Abstract (single-panel visual summary of the mechanism). Late-stage polish.

Use after Molecular Cell reviews arrive to triage the decision, prioritize the (often mechanism-completing) new experiments by impact × feasibility, and draft a point-by-point response that is respectful, evidence-led, and closes the mechanistic gaps reviewers demand. Do not run before the experiments and revision are actually done.

Use to build Molecular Cell's mandatory STAR Methods — the Key Resources Table, the Resource Availability subsections, Experimental Model and Subject Details, Method Details, and Quantification and Statistical Analysis, in the required order and with the reagent transparency Molecular Cell reviewers demand.