Claude Skills by brycewang-stanford

Use when designing or auditing a SenSys evaluation — energy and low-power measurement with a named instrument, real-testbed and deployment realism, honest sensor ground truth, on-device latency and memory, and same-hardware baselines, so the evidence meets SenSys's built-and-measured bar rather than a simulation or offline-benchmark one.

Use when positioning a SenSys paper against the sensing, embedded, IoT, and on-device-AI literature — sweeping the right venue lanes after the SenSys/IPSN/IoTDI merger, proving each citation's venue via dblp/ACM DL against the MobiCom/NSDI/IPSN traps, distinguishing your mechanism from the nearest prior system, and self-citing blind-safely.

Use when making a SenSys result reproducible across a different testbed — capturing energy-measurement method, hardware and firmware provenance, sensor ground-truth protocol, and deployment conditions while the testbed is still live, and deciding early which traces and firmware can legally and safely ship.

Use when interpreting SenSys's two-deadline, self-contained review model — what a first-deadline outcome means, that a reject may return at the second deadline only with a substantive revision and Response to Reviewers, how systems reviewers weigh energy and deployment evidence, and how to classify a notification before drafting a response.

Use when running the final pre-upload audit of a SenSys submission — confirming the right per-edition HotCRP site and which of the two deadlines is open, the AoE cutoff in local time, the 12/6-page double-column cap, the double-blind sweep including hardware and deployment leaks, and the resubmission-with-revision contract at the second deadline.

Use when deciding what goes in a SenSys paper's body versus its unlimited references and appendices versus HotCRP fields — keeping the double-column body carrying the argument, moving full protocols, extra plots, and derivations to the appendix, blinding anonymous artifact links, and keeping the Response to Reviewers out of the body.

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.

Use when planning a SenSys campaign against the two-deadline calendar — deciding which deadline to target and which edition it feeds, backward-scheduling so energy campaigns and long-term deployments finish before freeze, budgeting time for the resubmission-with-revision path, and sequencing fit, building, writing, and submission.

Use when drafting or revising a SenSys paper's abstract, introduction, and system sections — building the sensing-pain to mechanism to measured-behavior arc inside the double-column limit, putting the buildable system on the first page, reporting energy and latency as numbers not adjectives, and pairing every claim with a measurement.

Use when packaging an ACM SoCC artifact for the ACM Artifact Review and Badging scheme (Artifacts Available, Evaluated Functional and Reusable, Results Reproduced), covering what a cloud-systems evaluator checks first, reproducing tail-latency and cost results on a testbed, DOI-issuing archives, and the fact that whether SoCC runs a dedicated artifact-evaluation track for a given edition must be verified.

Use when drafting an ACM SoCC author response (rebuttal) during a round's response window, covering the single written turn, answering both the systems and the data/measurement reviewer, supplying the tail-latency and cost numbers reviewers ask for, staying within dual anonymity, and the fact that SoCC has no Major-Revision round to fall back on.

Use when preparing an accepted ACM SoCC paper for its camera-ready, covering de-anonymization, the acmart/sigconf final format and ACM metadata (DOI, ORCID, CCS concepts), integrating reviewer-required changes without scope creep, permanentizing released code and traces, the ACM rights/e-copyright form, and the presentation obligation in Singapore.

Use when designing or auditing ACM SoCC evaluations, covering real or realistic deployments over simulation, production or representative workloads and traces, tail-latency and cost as first-class metrics, fair tuned baselines, scale and multi-tenancy behavior, reproducible measurement pipelines, and matching evidence to the shape of each cloud claim.

Use when positioning an ACM SoCC submission against both the systems literature (OSDI, NSDI, EuroSys, ATC, SOSP, SoCC) and the data-management literature (SIGMOD, VLDB), writing delta-first contrast rather than a citation catalog, keeping self-citations dual-anonymous, and handling concurrent, preprint, and prior-version overlap.

Use when strengthening ACM SoCC reproducibility, covering the testbed and workload description, released code and traces, provenance pinning for measurement studies, reproducing tail-latency and cost (not just the mean), claim-to-evidence mapping, honest degrees of reproducibility, and consistency between what the paper reports and what the artifact regenerates.

Use when reasoning about how an ACM SoCC submission is evaluated, covering dual-anonymous review, the two-round-per-year model with the no-cross-round-resubmission rule, the author-response (rebuttal) period, the joint SIGMOD+SIGOPS reviewer pool that reads for both systems and data quality, and how SoCC's process differs from OSDI/NSDI/EuroSys.

Use when auditing an ACM SoCC (Symposium on Cloud Computing) research-paper submission for HotCRP readiness, covering the two-round abstract+paper deadlines, the acmart/sigconf 12-page (full) or 6-page (short) budget with unlimited references, dual-anonymous review, the systems-and-data reproducibility posture, and desk-reject triage before the AoE cutoff.

Use when deciding what belongs in an ACM SoCC paper body versus its released artifact and appendices, covering the acmart 12-page (full) or 6-page (short) budget with unlimited references, the rule that decision-critical evidence stays inside the reviewed pages, dual-anonymous supplementary material, and how to split a cloud-systems measurement paper between body and package.

Use when deciding whether a cloud-computing project belongs at ACM SoCC or should be routed to OSDI, NSDI, EuroSys, USENIX ATC, SOSP, or a data venue (SIGMOD/VLDB), leaning on SoCC's unique joint SIGMOD+SIGOPS identity, its welcome of measurement and experience papers alongside systems-building, and the model-swap and re-label tests.

Use when planning an ACM SoCC project timeline from venue fit through the two-round abstract+paper deadlines, the rebuttal, notification, camera-ready, and presentation, with backward-planning offsets for a cloud-systems measurement paper and honest handling of the two-rounds-per-year cadence and the no-cross-round-resubmission rule.

Use when revising an ACM SoCC paper for a cloud-scale problem an operator recognizes on the first page, a contribution at the systems-and-data intersection, evidence measured on a real or realistic deployment with tail latency and cost as first-class, dual-anonymous wording, and disciplined use of the acmart 12-page budget.

Use when stating assumptions, identification, and analytical properties (bias, consistency, efficiency, asymptotics, validity conditions) of a method in a Sociological Methods & Research (SMR) paper. Audits the theory and proof economy; does not design the Monte Carlo or the real-data illustration.

Use when building the real-data empirical illustration for a Sociological Methods & Research (SMR) paper — a demonstration that the method changes a substantive conclusion, not a decorative example. Designs the illustration; does not derive properties or design the Monte Carlo.

Use when positioning a Sociological Methods & Research (SMR) manuscript against the methods literature across sociology, statistics, econometrics, psychometrics, and computational social science, and avoiding sibling-journal misattribution. Maps the contribution onto prior methods; does not derive or simulate.

Use when sharpening the core methodological claim of a Sociological Methods & Research (SMR) paper — the new estimator/design/diagnostic and exactly what it fixes versus existing methods. Frames and bounds the contribution; does not derive its properties or run simulations.

Use when responding to a Sociological Methods & Research (SMR) decision letter — drafting the point-by-point response and revision plan for properties, simulations, the empirical illustration, software, and exposition under SMR's verbatim-comment response format. Plans the response; does not run new analyses itself.

Use when designing the Monte Carlo simulation study for a Sociological Methods & Research (SMR) paper — data-generating processes, competing methods, performance metrics, and the regimes where the method wins or breaks. Designs the simulation; does not derive properties or run the real-data illustration.

Use when preparing the released software, code, data, and reproducibility materials for a Sociological Methods & Research (SMR) paper — a usable package plus scripts that recreate every table, figure, and simulation, and the SMR data-and-code availability statement. Builds the reproducibility layer; does not write the manuscript.

Use when running the final Sociological Methods & Research (SMR) pre-submission check for ScholarOne — double-anonymization, separate title page, ASA style, ≤150-word non-parenthetical abstract, data-and-code availability statement, AI disclosure, and file formats. Preflights the submission; does not draft the science.

Use when designing tables and figures for a Sociological Methods & Research (SMR) paper — self-contained simulation grids, method-comparison tables, diagnostic plots, and equation/notation exhibits in ASA-styled format. Designs exhibits; does not write prose or run analyses.

Use when deciding whether a project clears the Sociological Methods & Research (SMR) bar — a genuine methodological contribution (develop, evaluate, or critically assess a method), not an application dressed as method. Screens fit and scope; does not derive properties or design simulations.

Use when sequencing a Sociological Methods & Research (SMR) manuscript from method-contribution fit through derivation and properties, Monte Carlo simulation, real-data empirical illustration, released software, ScholarOne submission, double-anonymized review, and rebuttal. Routes to the right SMR skill; does not itself draft sections.

Use when revising prose for a Sociological Methods & Research (SMR) manuscript — methods-paper introduction arc, ASA citation style, the ≤150-word non-parenthetical abstract, and clear exposition of estimands, assumptions, and results. Edits prose and conformance; does not derive or simulate.

Use when stress-testing the reasoning of a Sociological Theory (ST) manuscript — turning stated propositions into a valid, warranted argument that survives rival theories and counter-cases. Develops and audits the argument; it does NOT define the concepts (soctheory-theory-construction) or bound the theory's domain (soctheory-boundary-conditions).

Use when specifying the scope, domain, and limits of a Sociological Theory (ST) manuscript's theory — stating where it holds, where it does not, and what it does NOT claim. Bounds the theory as a contribution; it does NOT build the concepts (soctheory-theory-construction) or audit the reasoning (soctheory-argument-development).

Use when building the figures and typologies of a Sociological Theory (ST) manuscript — mechanism diagrams, process models, 2x2 typologies, and concept maps that carry theoretical work (never regression tables or data plots). Designs conceptual exhibits; it does NOT build the underlying theory (soctheory-theory-construction) or write the prose (soctheory-writing-style).

Use when articulating the theoretical contribution of a Sociological Theory (ST) manuscript — naming the new way of seeing it provides and differentiating it from prior theory. Frames the contribution; it does NOT build the theory (soctheory-theory-construction) or audit its reasoning (soctheory-argument-development).

Use when locating a Sociological Theory (ST) manuscript in a tradition and conversation — naming whose theory you extend, challenge, or synthesize, and avoiding sibling-journal misattribution. Positions the argument; it does NOT build the concepts (soctheory-theory-construction) or frame the novelty (soctheory-contribution-framing).

Use when writing the response document for a Sociological Theory (ST) Revise & Resubmit — structuring point-by-point replies that show the theory was genuinely strengthened, not just defended. Drafts the response; revise the manuscript's theory FIRST (soctheory-theory-construction / soctheory-argument-development) before writing the letter.

Use when you need to understand Sociological Theory (ST)'s double-anonymous peer review and interpret a decision letter focused on conceptual novelty and logical soundness. Explains the process and decision types; it does NOT draft the response document (that is soctheory-rebuttal).

Use when running the final pre-submission preflight for a Sociological Theory (ST) manuscript — Manuscript Central portal, ASA format and length cap, abstract, masking for double-anonymous review, ASA-style references, fee, ethics/originality, and required files. Theory-only journal; there is no data-availability or replication step.

Use when building the actual theory for a Sociological Theory (ST) manuscript — turning a positioned problem into defined concepts, explicit mechanisms, internally consistent propositions, and scope conditions. Constructs the theory; it does NOT stress-test the argument's validity against rivals (soctheory-argument-development) or set the domain limits (soctheory-boundary-conditions).

Use when deciding whether an idea is a genuine theoretical problem and a fit for Sociological Theory (ST) rather than an empirical study or a review essay. Screens the problem and venue fit; it does NOT build the theory (soctheory-theory-construction) or position it in a tradition (soctheory-literature-positioning).

Use when deciding which soctheory-* sub-skill to invoke next, or when sequencing a Sociological Theory manuscript from theoretical-problem framing through peer-review revision for a Sociological Theory (ST) submission. Routes — does not replace — the specialized skills.

Use when drafting or polishing a Sociological Theory (ST) manuscript so it reads as an argument for a broad theoretical readership, follows the ASA Style Guide, and fits ST's length cap (max ~14,500 words inclusive of footnotes, references, tables, figures, and appendices — verify current). Tightens prose and format; it does not invent content.

Use when packaging a TACAS (ETAPS) artifact for the ETAPS Artifact Badges (Available, Functional, Reusable), covering the two-round model (mandatory, PC-parallel evaluation for tool and tool-demo papers vs voluntary post-acceptance evaluation for research and case-study papers), what the AEC checks on the clean evaluation VM, DOI-issuing archives, and evaluator-proof documentation.

Use when drafting a TACAS (ETAPS) author response for the rebuttal window, covering the short single-round rebuttal, answering soundness and benchmark-fairness objections with checkable evidence, addressing artifact concerns for tool papers, respecting the per-category blind model when it applies, and reading which objections a rebuttal can and cannot move.

Use when preparing an accepted TACAS (ETAPS) paper for its Springer LNCS camera-ready, covering de-anonymization of a double-blind research paper, the llncs.cls format and LNCS metadata (ORCID, references, the Springer copyright/consent-to-publish form), the gold-open-access CC-BY licensing, integrating reviewer-required changes without scope creep, permanentizing artifact links, and adding earned ETAPS artifact badges to the title page.

Use when designing or auditing a TACAS (ETAPS) evaluation, covering shared verification benchmarks (SV-COMP-style task sets), fair baseline configuration and equal time budgets, honest wall-clock/scalability reporting on stated hardware, soundness checking of results, reproducibility on the clean artifact VM, and how a TACAS tool-paper evaluation differs from a SV-COMP competition entry.

Use when positioning a TACAS (ETAPS) submission against the verification literature across TACAS, CAV, VMCAI, FMCAD, SPIN, and journals (STTT, FMSD), writing delta-first contrast against the nearest tools and algorithms, crediting the benchmarks and solvers you build on, keeping self-citations anonymous for double-blind research papers, and handling competition-tool and prior-version overlap.