Claude Skills by brycewang-stanford

Use when planning an IEEE INFOCOM project timeline from venue fit through the two-step EDAS abstract-then-paper registration, the early-reject checkpoint, the December notification, the IEEE Xplore camera-ready with PDF eXpress and eCF, and presentation, with backward-planning offsets for a networking paper and honest handling of the single-summer deadline.

Use when revising an IEEE INFOCOM paper for a networking problem and system model stated up front, theorems or protocol design that pay off, evaluation proportional to the claim, defensive writing that pre-empts objections (because there is no rebuttal), double-blind wording, and disciplined use of the tight IEEEtran two-column page budget.

Use when the one-sentence computational/methodological claim of an INFORMS Journal on Computing (IJOC) manuscript is not sharp, or the contribution reads as application rather than computing. Sharpens the "what is new and by how much"; it does not run the experiments that back it.

Use when running and reporting the computational experiments — and assembling the reproducible code/data deposit — for an INFORMS Journal on Computing (IJOC) manuscript. Turns a designed protocol (see ijoc-methods) into defensible, reproducible results; it does not redesign the experiment.

Use when staking the computational/methodological contribution of an INFORMS Journal on Computing (IJOC) manuscript against OR/MS and CS prior art. Positions the advance relative to the right baselines and the right frontier; it does not invent citations.

Use when the method choice, baselines, and computational-experiment design need alignment for an INFORMS Journal on Computing (IJOC) manuscript — before the experiments are run at scale. Designs a fair, reproducible experimental protocol; it does not write the algorithm proofs (see ijoc-theory-development).

Use when drafting the response to an INFORMS Journal on Computing (IJOC) decision letter — turning referee objections (especially about experiments and reproducibility) into a point-by-point response with re-run evidence. Builds the rebuttal and revision plan; it does not run new analysis on its own (route to ijoc-data-analysis).

Use when calibrating expectations for the INFORMS Journal on Computing (IJOC) review cycle — the Area-Editor desk-reject gate, the undisclosed associate editor, single-blind reviewing, decision types, and whether a sibling journal fits better. Sets expectations and strategy; it does not draft the rebuttal (see ijoc-rebuttal).

Use when running the final pre-submission preflight for an INFORMS Journal on Computing (IJOC) submission via ScholarOne — page limit, LaTeX template, single-blind rules, technical-area choice, and the GitHub code/data deposit. Final checks; it does not draft content.

Use when the computational exhibits — performance profiles, runtime-vs-size plots, and results tables — are dense, misleading, or do not answer the question for an INFORMS Journal on Computing (IJOC) manuscript. Designs exhibits that make the computational claim legible; it does not generate the underlying results.

Use when the algorithm or model formulation, its correctness, and its theoretical guarantees are the bottleneck for an INFORMS Journal on Computing (IJOC) manuscript. Pins down formulation, complexity, and what the method provably does before experiments are finalized; it does not run the experiments.

Use when deciding whether a project is computing-first enough for an INFORMS Journal on Computing (IJOC) submission and which of its 10 technical areas fits. Scopes the contribution to the OR↔computing interface; it does not invent results or citations.

Use when deciding which ijoc-* sub-skill to invoke next, or when sequencing a manuscript from idea through rebuttal for an INFORMS Journal on Computing (IJOC) submission. Routes — it does not replace — the specialized skills.

Use when the prose, abstract, or introduction of an INFORMS Journal on Computing (IJOC) manuscript buries the computational advance or misreads the house voice. Makes the method land for an OR-meets-CS readership; it does not change the underlying results.

Use when packaging code, models, and audio artifacts for an INTERSPEECH paper — anonymous demo pages and sample audio during double-blind review, public release at camera-ready, checkpoint and recipe distribution, voice-data licensing and speaker-consent hygiene, and the ethics of releasing synthesis or cloning systems.

Use when INTERSPEECH reviews arrive on CMT and a rebuttal is due — triaging three-or-more speech reviewers with mixed science/engineering instincts, answering WER/MOS evidence doubts with material already in the 4-page record, keeping replies anonymous, and writing for the meta-reviewer who decides in June.

Use when an INTERSPEECH paper is accepted and the camera-ready, registration, and presentation chain begins — de-anonymizing for the ISCA Archive, restoring acknowledgments on the references page, meeting the author-registration requirement for proceedings inclusion, DOI metadata, and oral/poster preparation for the conference week.

Use when designing or auditing the experimental evidence for an INTERSPEECH paper — task-correct metrics (WER/CER, MOS/CMOS, EER/minDCF, PESQ/STOI), baselines reviewers accept, significance testing over utterances and seeds, condition coverage across speakers/noise/languages, and data hygiene for speech corpora.

Use when positioning an INTERSPEECH paper in the literature — tracing lineage through the ISCA Archive and its DOIs, covering the ICASSP/ASRU/SLT sibling circuit and challenge series, handling the speech-versus-NLP crossover canon, citing corpora properly, and avoiding the venue misattributions speech reviewers notice instantly.

Use when hardening the reproducibility of an INTERSPEECH paper — pinning corpus versions and official splits, publishing text-normalization and scoring rules that WER/EER silently depend on, documenting MOS listening-test protocols, reporting seeds and variance within 4 pages, and making toolkit recipes rerunnable.

Use when reasoning about how INTERSPEECH review actually works — area-based assignment inside ISCA's scientific program, multi-reviewer scoring and meta-review on CMT, what the rebuttal can and cannot move, oral/poster allocation, ISCA best student paper selection, and reading a decision letter for next-cycle strategy.

Use when auditing an INTERSPEECH submission before the CMT deadline — the strict 4-page-plus-references format, double-anonymous rules and the pre-deadline anonymity period, scientific-area and metadata choices, the post-deadline paper-update window, dual-submission policy, and the desk-reject triggers specific to ISCA's flagship.

Use when deciding what accompanies an INTERSPEECH paper beyond its 4 pages — audio sample pages and multimedia for listening-based judgment, what reviewers may ignore versus must see, the references-and-acknowledgments page's strict scope, and packaging extra analyses when no reviewed appendix exists.

Use when deciding whether a project belongs at INTERSPEECH, the ISCA flagship speech conference, or should be routed to ICASSP, ASRU/SLT, Odyssey, SSW, ACL/EMNLP, or a speech journal — testing whether spoken language is the contribution, matching subfields to the reviewer pool, and choosing between the 4-page and Long Paper tracks.

Use when managing an INTERSPEECH project across the annual ISCA cycle — backward-planning from the late-February deadline through the update window, spring review, June notification, camera-ready and registration coupling, and the September–October conference, including what to do in the current post-decision phase and 2027 planning.

Use when writing or compressing an INTERSPEECH paper into its 4 content pages — the abstract-and-index-terms opening, task-first framing for a mixed science/engineering readership, table and figure economy, protocol one-liners that preserve rigor under compression, and the cuts that shrink pages without shrinking claims.

Use when packaging an IPSN-lineage artifact for the ACM badges and the IPSN Best Research Artifact Award, covering hardware-plus-software artifacts (firmware, board files, datasets), what sensor-systems evaluators check first, DOI-issuing archives, evaluator-proof documentation for a physical system, and the separate post-acceptance timing.

Use when drafting an IPSN-lineage rebuttal, covering the double-blind response to sensor-systems reviewers on ground truth, baseline fairness, deployment realism, energy accounting, and simulation-vs-real-hardware doubts, without leaking identity and without promising experiments not yet run.

Use when preparing an accepted IPSN-lineage paper for camera-ready, covering de-anonymization, the ACM Primary Article Template and the dual ACM/IEEE metadata (CCS concepts, ORCID, DOI, IEEE PDF eXpress/e-copyright), integrating required changes without scope creep, permanentizing dataset/firmware links, and the artifact-award handoff.

Use when designing or auditing IPSN-lineage evaluations, covering real testbeds and deployments, ground-truth instrumentation, energy/latency/footprint measurement on real hardware, on-device/TinyML profiling, estimation-theoretic baselines and bounds, and matching evidence to the shape of each sensing claim across the IP and SPOTS tracks.

Use when positioning an IPSN-lineage submission against the sensor-networks and information-processing literature (IPSN, SenSys, MobiCom, MobiSys, INFOCOM, and signal-processing venues), writing delta-first contrast rather than a citation catalog, keeping self-citations double-blind, and handling concurrent, preprint, and prior-version overlap.

Use when strengthening IPSN-lineage reproducibility for a hardware/embedded/deployment artifact, covering firmware and board files, pinned toolchains, raw traces and calibration, honest degrees of reproducibility for a physical system, anonymized-but-runnable artifacts, and consistency between the paper and the package.

Use when reasoning about how an IPSN-lineage submission is evaluated, covering double-blind review, the per-track (IP / SPOTS) program committees, the rebuttal, Best Paper and Best Research Artifact judging, and how IPSN's process differs from SenSys's revision model, OpenReview venues, and CPS-IoT Week neighbors.

Use when auditing an IPSN-lineage submission for HotCRP readiness, covering the IP-vs-SPOTS track choice, the ACM Primary Article Template and ≤12-page inclusive budget, the double-blind sweep for hardware/deployment papers, dataset/artifact links, and desk-reject triage — routed to the current successor (SenSys) call because IPSN no longer runs standalone.

Use when deciding what belongs in an IPSN-lineage paper body versus its artifact, appendix, and demo/poster track, covering the ≤12-page ACM two-column budget, the rule that decision-critical evidence stays inside the reviewed pages, double-blind supplementary material, dataset release, and how to split a sensor-systems paper between body and package.

Use when deciding whether a sensing/embedded project is an IPSN Information-Processing (IP) contribution or a Sensor Platforms, Tools and Design Methods (SPOTS) contribution, and whether it should go to the IPSN lineage (now the merged SenSys at CPS-IoT Week), a CPS-IoT Week neighbor (RTAS/ICCPS/HSCC), MobiSys/MobiCom, INFOCOM, or a signal-processing journal.

Use when planning an IPSN-lineage project timeline from track/venue selection through the CPS-IoT Week deadline, double-blind submission, deployment and hardware logistics, rebuttal, the Best Research Artifact Award, and the dual ACM/IEEE camera-ready — with honest handling of the fact that IPSN merged into SenSys.

Use when revising an IPSN-lineage paper for a real sensing problem on the first page, a load-bearing information-processing or platform contribution, ground-truth methodology, energy/latency/accuracy budgets, honest deployment reporting, double-blind wording, and disciplined use of the ≤12-page ACM two-column budget.

Use when packaging IROS evidence for a skeptical reviewer even though IROS runs no formal artifact track — the robotics artifact stack of hardware ledger, logs, configs, code, and data, what an embodied-systems reviewer opens first, review-time anonymity versus acceptance-time public release, and making a claim auditable not asserted.

Use when responding to IROS reviews given the traditional no-rebuttal model — pre-answering objections in the paper and video before submission, addressing the meta-review through camera-ready edits, writing RA-L response letters for the journal pathway, and drafting reject-to-ICRA/CoRL/RA-L resubmission memos under double-anonymous rules.

Use when preparing an accepted IROS paper for IEEE Xplore camera-ready — de-anonymization from the double-anonymous cycle, integrating the meta-review, the IEEE electronic copyright form (eCF), the July final-paper deadline, registration and in-person presentation, and the public artifact release anonymity had blocked.

Use when designing or auditing IROS experiments — real-robot trial counts, success criteria set in advance, reset procedures, failure taxonomies, baseline fairness on matched hardware, sim-to-real gap reporting, small-n statistics, and the claim-to-evidence ladder that embodied-systems reviewers apply before they trust a demo.

Use when positioning an IROS submission against robotics-systems literature across ICRA, IROS, RSS, CoRL, RA-L, and T-RO, covering the lanes embodied-systems reviewers check, concurrent arXiv work, prior-version overlap, IEEE Xplore archival status, and keeping self-citations anonymous under the double-anonymous cycle.

Use when strengthening IROS reproducibility evidence — splitting rerunnable claims from auditable-only real-robot claims, the hardware specification ledger, calibration and parameter disclosure, log capture discipline, honest code/data availability statements, and sim-to-real accounting, all inside a page budget with no supplementary PDF.

Use when reasoning about IROS peer review — the PaperPlaza Associate-Editor/Editor pipeline, the traditional no-rebuttal single-notification model, how the video and embodied evidence steer reviewers, the 2026 double-anonymous posture, decision criteria for systems papers, and IEEE Xplore proceedings outcomes.

Use when auditing an IROS paper for the PaperPlaza upload — author PINs and metadata, the content-page limit with references counted in, IEEE two-column format, the 2026 double-anonymous rule, the 60-second/10 MB video attachment and its own deadline, dual-submission traps shared with ICRA and RA-L, and return-without-review triggers.

Use when preparing the IROS video attachment as evidence — the 60-second/10 MB limit, its own deadline, storyboarding uncut real trials and labeled failures, showing playback speed honestly, anonymizing footage under the double-anonymous cycle, and compensating for the fact that IROS provides no supplementary PDF.

Use when deciding whether a project is a strong IROS fit, routing among ICRA, RSS, CoRL, RA-L, T-RO, HRI, and CASE from IROS's seat on the fall IEEE/RSJ calendar, identifying the integrated-system contribution and its embodiment constraint, and sharpening the intelligent-robots-and-systems framing before writing begins.

Use when planning an IROS project timeline from venue fit through the spring paper deadline, the separate video deadline, the summer review silence, the June notification, the July camera-ready, IEEE Xplore publication, registration, and presentation, with backward-planning offsets for a real-robot paper on the fall IEEE/RSJ calendar.

Use when revising an IROS paper for a task-first opening, an integrated-system narrative, the references-counted-in page budget with no supplementary PDF, double-anonymous wording, demo-speak-to-numbers rewrites, and figure-first structure that carries the argument in the body for embodied-systems reviewers.