Claude Skills by brycewang-stanford

Use when deciding which expecon-* sub-skill to invoke next, or when sequencing manuscript work from design through rebuttal for an Experimental Economics (ExpEcon) submission. Routes — it does not replace — the specialized skills.

Use when the prose of an Experimental Economics (ExpEcon) manuscript buries the design or the result, or when the intro/abstract do not land for an experimentalist reader. Polishes structure and voice; it does not change the analysis.

Use when packaging a USENIX FAST artifact for the USENIX Artifact Evaluation scheme (Artifacts Available, Artifacts Functional, Results Reproduced), covering what a storage AEC checks first, DOI-issuing archives, the artifact appendix, and the special challenges of storage artifacts that need specific devices, large traces, or long endurance runs on the separate post-acceptance timeline.

Use when drafting USENIX FAST author responses, covering the short pre-notification rebuttal during the author-response period and — distinctively — the one-shot-revision change ledger that maps every required change (including any newly required storage experiments) to a concrete result, resubmitted at the next deadline for a terminal accept/reject.

Use when preparing an accepted USENIX FAST paper for its open-access camera-ready, covering de-anonymization, the USENIX two-column template and the larger camera-ready page allowance, integrating shepherd- or revision-required changes without scope creep, permanentizing trace and code availability, adding the artifact appendix and USENIX badges, and meeting the final-files deadline.

Use when designing or auditing a USENIX FAST storage evaluation, covering real devices and firmware, device-state control (aging, preconditioning, fill, TRIM), standard workloads and traces (SNIA IOTTA, YCSB, filebench, fio), write amplification, tail latency, endurance and wear, crash-consistency testing, fair baselines, and matching the metric to the shape of each storage claim.

Use when positioning a USENIX FAST submission against the storage-systems literature across FAST, OSDI, ATC, SOSP, EuroSys, HotStorage, MSST, and the storage journals (ACM TOS), 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 USENIX FAST reproducibility and open-science evidence, covering device and firmware provenance, device-state disclosure, trace availability and replay, claim-to-evidence mapping, honest degrees of reproducibility on hardware that ages and varies, and consistency between what the paper says and what the artifact contains.

Use when reasoning about how a USENIX FAST submission is evaluated, covering double-blind program-committee review with outside referees, the author-response (rebuttal) period, the Accept / Accept-with-shepherding / One-shot-Revision / Reject decision set, how a one-shot revision differs from a journal R&R and from OSDI/ATC handling, and where author leverage exists.

Use when auditing a USENIX FAST submission for HotCRP readiness, covering the choice between the Spring and Fall deadlines, abstract registration, the USENIX two-column template and 12-page (long) / 6-page (short) limit excluding references, double-blind anonymization, the artifact-availability story, and desk-reject triage before the AoE cutoff.

Use when deciding what belongs in a USENIX FAST paper body versus its artifact and appendices, covering the USENIX two-column page budget (references excluded), the rule that decision-critical storage evidence stays inside the reviewed pages, double-blind supplementary material, and how to split a storage paper between body and package.

Use when deciding whether a storage project belongs at USENIX FAST or should be routed to OSDI, ATC, NSDI, EuroSys, HotStorage, MSST, SYSTOR, or a storage journal (ACM TOS), and when distinguishing FAST from general-systems siblings by storage-contribution shape, real-device evidence, and the two-deadline calendar.

Use when planning a USENIX FAST project timeline from venue fit through choosing a Spring or Fall deadline, double-blind submission, the author-response period, shepherding or a one-shot revision, artifact evaluation, and the open-access camera-ready, with backward-planning offsets tuned to storage evaluation and honest handling of the two-deadline cycle.

Use when revising a USENIX FAST paper for a storage contribution on the first page, a design/mechanism narrative a storage reviewer can follow, an evaluation framed as the storage cost it changes (write amplification, tail latency, endurance, crash consistency), double-blind wording, and disciplined use of the USENIX two-column page budget.

Use when preparing the accountability artifacts that accompany an ACM FAccT paper — datasheets for datasets, model cards, data statements, audit and impact-assessment documentation, and released code/data — since FAccT's culture centers documentation and accountability infrastructure rather than a formal ACM artifact-badging track; covers what makes each genre credible, anonymized-review versus public-release versions, and consistency with the paper's harm claims.

Use when drafting ACM FAccT author responses — the short factual-correction rebuttal after preliminary reviews, and, distinctively for the 2026-new process, the Revise-and-resubmit round where you address Area-Chair-prioritized concerns from a mixed CS+law+social-science panel, map each to a concrete change, and survive a re-review while keeping mutual anonymity.

Use when preparing an accepted ACM FAccT paper for camera-ready — de-anonymizing and adding the withheld Positionality/Acknowledgements statements, switching to the acmart sigconf proceedings format, ACM metadata (DOI, ORCID, CCS concepts, rights), the two-round camera-ready calendar for Accept vs Revise papers, ACM Open Access, finalizing datasheets/model cards, and integrating required changes without scope creep.

Use when designing or auditing ACM FAccT empirical work — quantitative fairness audits with disaggregated metrics and fair baselines, qualitative and participatory studies with coding and reflexivity, mixed-methods designs, sound handling of protected attributes and proxies, consent and IRB for human-subjects and community-facing work, and matching evidence to the shape of a fairness/accountability/transparency claim.

Use when positioning an ACM FAccT submission across its many disciplinary lanes — algorithmic fairness/ML, HCI, law and policy, STS and critical theory, and prior FAccT/FAT* proceedings — writing delta-first contrast that a mixed reviewer pool will accept, citing borrowed constructs to their real origin, keeping self-citations mutually anonymous, and declaring overlap with workshops, preprints, and prior versions.

Use when strengthening ACM FAccT transparency and reproducibility — releasing code, data, and analysis for quantitative audits; documenting datasets and models with datasheets, model cards, and data statements; making qualitative and participatory work auditable without breaking confidentiality; pinning provenance for scraped and model-generated data; and keeping the paper, the supplementary material, and any released artifact consistent.

Use when reasoning about how an ACM FAccT submission is evaluated — mutually-anonymous review by a mixed CS+law+social-science pool matched via author-selected focus areas, Area Chairs, the short factual-correction rebuttal, the new Accept/Revise/Reject decision with a revise-and-resubmit round, and how FAccT's interdisciplinary process differs from a pure-ML conference's single-shot rebuttal.

Use when auditing an ACM FAccT submission for OpenReview readiness — the mandatory abstract-registration gate with focus-area selection, the acmart anonymous/review PDF, the 14-page (+1 endmatter) budget, mutual anonymity, the required Generative AI Usage Statement and optional ethics/adverse-impacts statements, archival vs non-archival choice, and desk-reject triage before the deadline.

Use when deciding what belongs in an ACM FAccT paper body versus its endmatter statements, appendices, and supplementary material — the 14-page acmart budget, the extra endmatter page for ethics/adverse-impacts statements, the rule that decision-critical evidence stays in the reviewed pages, mutually-anonymous supplementary material, and how to split an interdisciplinary paper between body, endmatter, and artifact.

Use when deciding whether a responsible-AI project belongs at ACM FAccT or should route to a pure-ML venue (NeurIPS/ICML/ICLR), an HCI venue (CHI/CSCW), a law/policy venue, or an AI-ethics venue (AIES), by testing whether fairness, accountability, or transparency is a first-class contribution and whether the interdisciplinary framing is native rather than bolted on.

Use when planning an ACM FAccT project timeline from venue fit through abstract registration, OpenReview submission, the rebuttal window, the new Accept/Revise/Reject revise-and-resubmit round, two-round camera-ready, and in-person presentation, with backward-planning offsets for an interdisciplinary responsible-AI paper and honest handling of the single annual deadline.

Use when revising an ACM FAccT paper so that a fairness/accountability/transparency contribution is legible on the first page to a mixed CS+law+social-science reviewer pool, claims are scoped to who is affected, limitations and harms are argued rather than recited, the interdisciplinary framing is native, and the acmart page budget and endmatter statements are used well.

Use when planning the durable evidence objects around a FOCS (IEEE Symposium on Foundations of Computer Science) paper — a venue with no artifact track where the public arXiv/ECCC full version is the artifact of record, plus proof certificates, checker code, and the IEEE Xplore version's supporting role.

Use when managing author-side communication around a FOCS (IEEE Symposium on Foundations of Computer Science) submission, where no rebuttal round exists — discharging objections inside the paper before submission, handling rare chair-mediated queries, and converting a rejection into a disciplined autumn resubmission.

Use when converting a FOCS (IEEE Symposium on Foundations of Computer Science) acceptance into its deliverables — the IEEE proceedings version with copyright and de-anonymization steps, the public arXiv/ECCC full version the CFP expects, the New York talk, and award-eligibility hygiene.

Use when deciding whether and how computation appears in a FOCS (IEEE Symposium on Foundations of Computer Science) paper — a venue that accepts on theorems with no evaluation section expected — covering machine-verified case analyses, computer-discovered constructions, and honest illustrative plots.

Use when building the related-work and citation apparatus of a FOCS (IEEE Symposium on Foundations of Computer Science) paper — tracing result lineages across the FOCS/STOC record, citing arXiv/ECCC full versions with version pins, handling concurrent preprints, and keeping self-citation double-blind-safe.

Use when hardening a FOCS (IEEE Symposium on Foundations of Computer Science) paper's checkability — the theory analogue of reproducibility — via hypothesis ledgers, single-source theorem statements that cannot drift between submission and arXiv versions, audits of imported theorems, and certificates for machine-checked steps.

Use when reasoning about how a FOCS (IEEE Symposium on Foundations of Computer Science) submission is evaluated — the TCMF-sponsored program committee, subreferee delegation, double-blind norms the venue adopted years before STOC, the summer decision arc, and what each outcome means for a theory paper.

Use when running the final pre-upload audit of a FOCS (IEEE Symposium on Foundations of Computer Science) submission — the April HotCRP deadline clock, the abstract-references-plus-ten-pages attention rule, the 11-point single-column format floor, PDF security restrictions, double-blind checks, and SIGACT publication-policy compliance.

Use when architecting everything after page ten of a FOCS (IEEE Symposium on Foundations of Computer Science) submission — a venue with no separate supplement channel where the paper itself continues past the guaranteed-read window — covering body organization, proof placement, and navigation for the discretionary reader.

Use when deciding whether a theoretical-computer-science result belongs at FOCS (IEEE Symposium on Foundations of Computer Science) — testing foundations-level significance, weighing the April deadline against sibling theory venues like STOC, SODA, CCC, ITCS, or CRYPTO, and applying the CFP's broaden-the-reach clause.

Use when planning a FOCS (IEEE Symposium on Foundations of Computer Science) cycle end to end — working backward from the April 1 deadline, managing the live post-submission summer of the 2026 cycle, coordinating with the STOC beat, preparing the November conference, and scheduling a FOCS 2027 attempt.

Use when drafting or revising a FOCS (IEEE Symposium on Foundations of Computer Science) paper — making the first ten pages carry the whole case to a broad theory committee, pairing informal and formal theorem statements, keeping single-column 11-point prose readable, and writing double-blind-safe self-references.

Use when packaging an ESEC/FSE artifact for the ACM Artifact Review and Badging scheme (Artifacts Available, Evaluated Functional and Reusable, Results Reproduced), covering what SIGSOFT evaluators check first, DOI-issuing archives, evaluator-proof documentation, and the separate post-acceptance artifact deadline.

Use when drafting ESEC/FSE author responses, covering the initial-review rebuttal and — distinctively — the journal-style Major Revision response letter that must stay double-anonymous, map every reviewer request to a concrete tracked change, and survive re-review by the original reviewers under PACMSE.

Use when preparing an accepted ESEC/FSE paper for its PACMSE camera-ready, covering de-anonymization, the ACM Primary Article Template and PACMSE journal metadata (DOI, ORCID, CCS concepts), integrating reviewer-required changes without scope creep, permanentizing the Data Availability links, and the ACM artifact-badge handoff.

Use when designing or auditing ESEC/FSE empirical evaluations, covering real subject systems, fair baselines, SE-standard statistics and effect sizes, qualitative and mixed-methods rigor, contamination-aware LLM ablations, provenance for mining studies, and matching evidence to the shape of each software-engineering claim.

Use when positioning an ESEC/FSE submission against the software-engineering literature across ICSE, FSE, ASE, ISSTA, MSR, and the SE journals (EMSE, TSE, TOSEM), writing delta-first contrast rather than a citation catalog, keeping self-citations double-anonymous, and handling concurrent, preprint, and prior-version overlap.

Use when strengthening ESEC/FSE reproducibility and open-science evidence, covering the Data Availability statement, anonymized-but-runnable artifacts, provenance pinning for mining and LLM studies, claim-to-evidence mapping, honest degrees of reproducibility, and consistency between what the paper says and what the artifact contains.

Use when reasoning about how an ESEC/FSE research submission is evaluated, covering double-anonymous "heavy" review, the at-least-three-reviewer PC model, the Accept / Major Revision / Reject decision categories, the journal-style revise-and-resubmit round of PACMSE, and how FSE's process differs from ICSE's cycles and ISSTA's rounds.

Use when auditing an ESEC/FSE research-track submission for HotCRP readiness, covering the mandatory paper-registration step, the ACM Primary Article Template page budget, double-anonymous "heavy" anonymity, the open-science Data Availability statement, PACMSE publication, and desk-reject triage before the AoE cutoff.

Use when deciding what belongs in an ESEC/FSE paper body versus its anonymized artifact and appendices, covering the ACM-template page budget, the rule that decision-critical evidence stays inside the reviewed pages, double-anonymous supplementary material, and how to split an empirical-SE paper between body and package.

Use when deciding whether a software-engineering project belongs at ESEC/FSE or should be routed to ICSE, ASE, ISSTA, MSR, ICSME, or an SE journal (EMSE/TSE/TOSEM), and when distinguishing FSE from its sibling general-SE flagship ICSE by contribution shape, evidence maturity, and the PACMSE journal-style fit.

Use when planning an ESEC/FSE project timeline from venue fit through paper registration, submission, the journal-style Major Revision round, artifact evaluation, PACMSE camera-ready, and presentation, with backward-planning offsets for an empirical-SE paper and honest handling of the single-annual-deadline cycle and cycle-hopping.

Use when revising an ESEC/FSE paper for a practitioner-grounded software-engineering contribution on the first page, research-question contracts, a threats-to-validity section that argues rather than recites, evidence proportional to the claim, double-anonymous wording, and disciplined use of the ACM-template page budget.