Claude Skills by brycewang-stanford

Use when revising an ACM SIGCOMM paper for its house style — leading with measured operational pain, stating a design principle rather than a behavior, pairing every claim with testbed/trace/deployment evidence, reporting tails instead of superlatives, and fitting the argument into 12 figure-inclusive pages while keeping blinding clean.

Use when pursuing the Graphics Replicability Stamp (GRSI) or Code Replicability in Computer Graphics (CRCG) recognition for an accepted SIGGRAPH / TOG paper, covering how graphics replicability differs from ACM artifact badging, what volunteers actually run, deterministic result reproduction, Software Heritage archiving, and the separate post-acceptance timing.

Use when writing the SIGGRAPH / SIGGRAPH Asia Technical Papers rebuttal, the single 1000-word text-only author response uploaded during the rebuttal window to correct factual errors and answer specific reviewer questions before the Technical Papers Committee meeting, and when planning the change list for a conditionally accepted paper's second-stage revision.

Use when preparing the final version of a conditionally accepted SIGGRAPH / SIGGRAPH Asia Technical Paper for publication in ACM Transactions on Graphics, covering the second-stage committee verification, TOG journal metadata and DOI, ACM rights and CCS concepts, final results video and representative image, and permanent code/data links.

Use when designing or auditing the evaluation of a SIGGRAPH / TOG paper, covering head-to-head comparisons against the strongest prior method, ablations, performance/timing reporting with hardware, image/geometry quality metrics, perceptual and user studies, and matching the evidence to the graphics claim shape.

Use when writing or auditing the related-work positioning of a SIGGRAPH / TOG paper, covering the computer-graphics literature lanes (rendering, geometry, animation, simulation, imaging, fabrication, learning-for-graphics), capability-delta positioning against the strongest prior method, and correct attribution across SIGGRAPH, SIGGRAPH Asia, TOG, EG/CGF, and sibling venues.

Use when building the reproducibility story for a SIGGRAPH / TOG paper, covering deterministic result regeneration, scene/mesh/weight provenance, hardware and timing disclosure, floating-point and GPU non-determinism, and a code/data release that a reader or a Graphics Replicability Stamp volunteer can actually run.

Use to model the SIGGRAPH / SIGGRAPH Asia Technical Papers review pipeline and calibrate expectations, covering the single 6-point score scale, the primary/secondary/tertiary reviewer structure, the 1000-word rebuttal, the Technical Papers Committee meeting, conditional acceptance with second-stage verification, and the dual-track Journal-vs-Conference decision.

Use when auditing an ACM SIGGRAPH / SIGGRAPH Asia Technical Papers submission for Linklings readiness, covering the two-step form-then-upload deadline, the acmart (>=2.16) format and the 7-page conference-track budget, the dual-track vs Journal-only choice, the mandatory representative image and supplemental video, and desk-risk triage before the UTC cutoff.

Use when planning the SIGGRAPH / TOG supplemental package, especially the results video that reviewers weight heavily, plus comparison galleries, additional results, code and data, and appendices, and when deciding what evidence must live in the 7-page body versus the supplemental material.

Use before committing a project to SIGGRAPH / SIGGRAPH Asia / TOG, to decide whether the contribution is graphics-shaped and which venue and track fit, routing among SIGGRAPH, SIGGRAPH Asia, direct-to-TOG, and siblings (CVPR/ICCV, CHI/UIST, Eurographics/EGSR/SGP/SCA/HPG/I3D), and whether to aim dual-track or Journal-only.

Use to plan a SIGGRAPH or SIGGRAPH Asia Technical Papers campaign backward from the deadline, covering the two annual cycles, the form-then-upload two-step submission, the rebuttal window, the Technical Papers Committee decision, conditional-accept second-stage revision, TOG camera-ready, and the in-person presentation.

Use when structuring or revising a SIGGRAPH / TOG technical paper, covering the teaser figure, a results-first first page, the graphics contribution framing (technique + quality/performance), comparison-driven evaluation, honest limitations, and the acmart 7-page discipline for the conference track.

Use when packaging code, run files, test collections, or judgments for a SIGIR submission — deciding between an artifact inside a full/short paper and a standalone Resources track paper, building reviewer-runnable IR repositories, run-file and qrels hygiene, licensing and datasheets, and single- vs double-anonymous handling.

Use when reviews arrive for a SIGIR submission and the authors must decide how to answer — triaging IR-reviewer objections (weak baselines, missing significance tests, collection choice), writing within whatever response mechanism the current SIGIR cycle actually offers, and planning the resubmission path if the answer is no.

Use when an accepted SIGIR paper must become the ACM Digital Library version of record — de-anonymizing the sigconf source, CCS concepts and keywords, the e-rights form, TAPS source upload and proof checking, restoring real system and dataset names, and the April camera-ready window before the July conference.

Use when designing or auditing the empirical program of a SIGIR paper — choosing test collections that match the claim, metric-cutoff discipline, paired significance testing with multiple-comparison correction, baseline tuning symmetry, ablations that isolate mechanisms, efficiency reporting, and LLM-era evaluation pitfalls.

Use when positioning a paper against the information-retrieval literature for SIGIR — tracing lineage through SIGIR/TOIS/TREC canon, contrasting mechanisms with the nearest recent SIGIR papers, avoiding venue misattribution (DPR is EMNLP, ANCE is ICLR, NCF is WWW), and handling arXiv-era concurrent work in a fast-moving field.

Use when strengthening the reproducibility of a SIGIR paper or preparing a SIGIR Reproducibility track submission — pinning the retrieval pipeline, seeds and variance for neural rankers, documenting collection versions and index settings, and structuring a reproduction study of published IR results with honest divergence analysis.

Use when reasoning about how SIGIR evaluates submissions — the per-track OpenReview machinery, double-blind full/short review versus single-anonymous Resources review, the PC-member nomination duty, what IR reviewers score (evaluation validity above novelty claims), the ACM Peer Review Policy layer, and how decisions land.

Use when auditing a SIGIR full or short paper before the deadline — the 9-page vs 4-page budgets with appendices counted inside, ACM sigconf anonymization, per-track OpenReview groups, the PC-member nomination duty, cross-track double-submission bans, AI-use disclosure, and desk-reject triage for the ACM SIGIR conference.

Use when deciding what goes inside a SIGIR paper's page budget versus the cited repository — SIGIR counts appendices inside the 9-page (full) and 4-page (short) limits with only references free, so overflow material must be re-homed into run files, repository docs, or cut, without hiding review-critical evidence outside the paper.

Use when deciding whether a project belongs at SIGIR and in which of its tracks — testing whether retrieval is the contribution or the plumbing, forking across full/short/resources/reproducibility/perspectives/industry, and routing misfits to ECIR, CIKM, WSDM, CHIIR, ICTIR, RecSys, TheWebConf, or NLP/ML venues.

Use when planning a SIGIR project calendar — backward-planning from the January-pattern abstract/paper deadlines to the July conference, sequencing evidence freeze, significance testing, and anonymization, coordinating multi-track decisions, and wiring the SIGIR/ECIR/CIKM/WSDM/SIGIR-AP fallback calendar into one pipeline.

Use when drafting or revising prose for a SIGIR paper — the IR register that leads with task, collection, and metric; claim sentences calibrated to significance results; first-page architecture for retrieval contributions; table-centric argumentation; and compressing into the 9-page budget without cutting soundness.

Use when packaging an ACM SIGMETRICS artifact for the ACM Artifact Review and Badging scheme (Artifacts Available, Evaluated Functional and Reusable, Results Reproduced), covering what performance-evaluation evaluators check first (does the simulation regenerate the figures and match the analysis?), DOI-issuing archives, evaluator-proof documentation, and confirming whether an artifact track runs this cycle.

Use when responding to ACM SIGMETRICS reviews, covering any initial rebuttal and — distinctively — the one-shot revision response letter that must map every item on the reviewers' required-changes list to a concrete change in the revised POMACS paper, resubmitted to a subsequent rolling deadline and re-reviewed once by the original reviewers under double-anonymity.

Use when preparing an accepted ACM SIGMETRICS paper for its POMACS camera-ready, covering de-anonymization, the acmsmall template and POMACS journal metadata (DOI, ORCID, CCS concepts), incorporating the shepherd's required changes without scope creep, permanentizing artifact links, and the ACM artifact-badge handoff.

Use when designing or auditing ACM SIGMETRICS evaluations, covering theorem-plus-validation rigor, stating and testing modeling assumptions, analysis-vs-simulation agreement, real workloads and traces, fairly tuned baselines, statistics and confidence intervals for stochastic systems, learning guarantees, measurement provenance, and matching evidence to the shape of each performance claim.

Use when positioning an ACM SIGMETRICS submission against the performance-evaluation literature across SIGMETRICS/POMACS, Performance Evaluation, QUESTA, TON, and the systems/learning/measurement neighbors (NSDI/OSDI, IMC, NeurIPS/ICML), writing delta-first contrast rather than a citation catalog, keeping self-citations double-anonymous, and handling concurrent and prior-version overlap.

Use when strengthening ACM SIGMETRICS reproducibility, covering proofs and their assumptions as reproducible artifacts, seeded simulators whose figures regenerate and match the analysis, measurement/trace provenance, claim-to-evidence mapping, honest degrees of reproducibility, and consistency between what the paper proves/measures and what the artifact contains.

Use when reasoning about how an ACM SIGMETRICS submission is evaluated, covering the hybrid conference-journal model, double-anonymous review, the three first-round outcomes (Accept-with-shepherding / One-Shot Revision / Reject), the one-shot revision resubmitted to a subsequent rolling deadline, the 12-month resubmission bar, and how SIGMETRICS differs from IMC, SIGCOMM, and NSDI.

Use when auditing an ACM SIGMETRICS submission for HotCRP readiness, covering the choice among the three rolling deadlines (summer/fall/winter), the separate abstract-registration step, the 20-page single-column acmsmall budget plus unlimited references, double-anonymous review (and the Operational Systems Track exception), track selection, POMACS publication, and desk-reject triage before the AoE cutoff.

Use when deciding what belongs in an ACM SIGMETRICS paper body versus its appendices and anonymized artifact, covering the 20-page single-column acmsmall budget, the rule that decision-critical claims (theorem statements, assumptions, headline validation) stay inside the reviewed pages, full proofs in appendices, double-anonymous supplementary material, and how to split a proof-plus-measurement paper.

Use when deciding whether a computer-systems performance project belongs at ACM SIGMETRICS or should be routed to IMC, SIGCOMM/NSDI/OSDI, INFOCOM, a learning venue (NeurIPS/ICML), or a performance journal (Performance Evaluation/TON/QUESTA), and when picking the right SIGMETRICS track (Theory / Measurement & Applied Modeling / Learning / Operational Systems).

Use when planning an ACM SIGMETRICS project timeline across the three rolling deadlines (summer/fall/winter), from venue fit through abstract registration, submission, shepherding, the one-shot revision round, POMACS publication, and presentation, with backward-planning offsets for a performance-evaluation paper and honest handling of the rolling-deadline cadence and the 12-month resubmission bar.

Use when revising an ACM SIGMETRICS paper for a rigorously stated performance contribution on the first page, explicit modeling assumptions and their validity, theorems paired with numerical/empirical validation, evidence proportional to the claim, double-anonymous wording, and disciplined use of the 20-page single-column acmsmall budget.

Use when preparing a SIGMOD paper's code and data for the Availability & Reproducibility Initiative (ARI), covering the post-acceptance opt-in, HotCRP artifact registration, the Artifacts Available / Artifacts Evaluated / Results Reproduced badges, evaluator criteria, and the Best Artifact award path.

Use when writing SIGMOD author feedback during a PACMMOD round or the revision letter after a major/minor-revision verdict, covering the mid-round feedback window, the four-page letter limit, per-reviewer change highlighting, the extra content page, and anonymity that must hold through resubmission.

Use when converting an accepted SIGMOD research paper into its PACMMOD journal version, covering the port from the ACM submission template to PACMMOD format, de-anonymization, per-round issue placement, ACM DL metadata, conference presentation logistics, and the post-acceptance artifact and ARI handoff.

Use when designing or auditing the evaluation of a SIGMOD paper, covering workload realism and standard benchmark usage, baseline tuning fairness, scalability and tail-latency methodology, ablations that isolate the mechanism, and the setup disclosure a data-systems PC demands before trusting any speedup.

Use when positioning a SIGMOD submission against the data-management literature, covering coverage across SIGMOD/PACMMOD, PVLDB, ICDE, TODS, and PODS lines, decades-deep systems history, concurrent papers in rolling venues, industrial-system citations, and PACMMOD's substantial-overlap exclusivity rule.

Use when hardening the reproducibility story of a SIGMOD submission, covering PACMMOD's expectation that code, data, scripts, and notebooks be shared, experiment provenance from config to figure, dataset and workload disclosure, variance reporting for systems numbers, and alignment with later ARI badging.

Use when reasoning about how a SIGMOD research paper moves through a PACMMOD round, covering double-anonymous CMT reviewing, the author feedback phase, accept/reject/revision verdicts, the one-month revision window, the 12-month rejection embargo, and how database PC members actually weigh evidence.

Use when readying a SIGMOD research-track submission for a PACMMOD round, covering the abstract-plus-COI pre-deadline, Microsoft CMT mechanics, the 12-page ACM-template limit, double-anonymous rules, the 10-paper author cap, the 12-month rejection embargo, and desk-reject hazards.

Use when deciding what accompanies a SIGMOD submission beyond the 12 pages, covering extended technical reports, anonymized code and data links that survive multi-round review, appendix placement relative to the unlimited reference pages, and what reviewers actually open during a PACMMOD round.

Use when judging whether a project belongs at SIGMOD's research track, comparing it against PVLDB's rolling model, ICDE, PODS, KDD, CIDR, and TODS, weighing the industrial track for deployment papers, and testing whether the contribution is genuinely a data-management result rather than an application that touches data.

Use when planning a SIGMOD project calendar under the PACMMOD round system, covering round selection and hopping, backward planning from abstract and paper cutoffs, the feedback and revision windows, embargo-aware contingencies, and coordinating a systems-building team against quarterly deadlines.

Use when revising a SIGMOD research paper's prose and structure, covering the data-management framing readers expect on page one, running examples and architecture figures, scoping systems claims to measured workloads, third-person anonymity phrasing, and fitting a systems argument into 12 ACM-template pages.

Use when deciding how code, computations, or data attach to a SODA (ACM-SIAM Symposium on Discrete Algorithms) paper — SODA itself runs no artifact track, so this skill covers computer-assisted proof evidence, implementation companions, and when to route the artifact to co-located ALENEX's formal artifact evaluation instead.