Claude Skills by brycewang-stanford

Use when positioning the contribution of an American Economic Review: Insights (AER: Insights) short-format manuscript against the closest published work in one or two tight paragraphs. Stakes the gap concisely; it does not write the full literature review (there is no room for one).

Use when responding to an American Economic Review: Insights (AER: Insights) conditional-accept decision — addressing the editor's letter within the short window, usually without a second referee round. Drafts a concise, decisive response and revision plan; it does not redo the analysis (see aeri-robustness / aeri-identification).

Use when calibrating expectations for the fast, decisive American Economic Review: Insights (AER: Insights) review process — conditional-accept-or-reject decisions, the single-round model, and pre-empting the objections a short paper cannot afford. Explains the process and stress-tests the paper; it does not write the response letter (see aeri-rebuttal).

Use when assembling the data and code deposit for an American Economic Review: Insights (AER: Insights) short-format manuscript to pass the AEA Data and Code Availability Policy and the AEA Data Editor's pre-publication reproducibility check. Builds the package and README; it does not run the analysis.

Use when deciding which robustness checks belong in the few in-text words of an American Economic Review: Insights (AER: Insights) short-format manuscript versus the online Supplemental Appendix. Triages checks against the length cap; it does not design the identification (see aeri-identification).

Use when running the final pre-submission preflight for American Economic Review: Insights (AER: Insights) via the AEA/ScholarOne submission system — the word-count and exhibit-count gates, abstract limit, fees, author metadata, declarations, and the AEA Data and Code Availability Policy. Final checks; it does not draft content.

Use when building or trimming the exhibits of an American Economic Review: Insights (AER: Insights) short-format manuscript to the hard five-exhibit budget, one page each, no significance asterisks. Designs the minimum exhibit set; it does not run the analysis behind them.

Use when a model — a full theory paper's argument or the structural/conceptual scaffolding behind an empirical AER: Insights short-format manuscript — needs to be made minimal, so it carries the single insight in a few pages. Keeps only what the insight requires; it does not develop a general framework.

Use when deciding whether a project is the ONE crisp, important, well-identified insight that an American Economic Review: Insights (AER: Insights) short-format manuscript requires, rather than a multi-result paper for AER or a field paper for the AEJ family. Tests single-insight fit; it does not run the analysis.

Use when deciding which aeri-* sub-skill to invoke next, or when sequencing work on a short-format manuscript from topic selection through the conditional-accept response for an American Economic Review: Insights (AER: Insights) submission. Routes — it does not replace — the specialized skills.

Use when revising an American Economic Review: Insights (AER: Insights) short-format manuscript to lead with the result, fit the hard word cap (7,000 words minus 200 per exhibit), and write the ≤100-word abstract. Enforces the length budget and the lead-with-the-result arc; it does not change the analysis.

Use when preparing an accepted ASE (IEEE/ACM Automated Software Engineering) paper's tool and data for the Artifact Evaluation track, targeting the ACM Artifacts Available and Artifacts Reusable badges on the track's own deadline, with the badge shown on the paper's front page in both IEEE Xplore and the ACM Digital Library.

Use when drafting ASE (IEEE/ACM Automated Software Engineering) author responses, covering the double-anonymous rebuttal that must first survive the early-rejection gate and — distinctively — the criteria-bound revision-round summary-of-changes that maps every stated revision criterion to a concrete change and is re-checked against those criteria.

Use when preparing the ASE (IEEE/ACM Automated Software Engineering) camera-ready after acceptance or a successful revision, covering systematic de-anonymization, the extra content page, the mandatory Data Availability finalization, the correct IEEE/ACM template and metadata, permanentized artifact links, and dual IEEE-Xplore/ACM-DL production checks.

Use when designing or auditing the evaluation of an ASE (IEEE/ACM Automated Software Engineering) paper, covering real subject systems, fair runnable tool baselines, task-matched effectiveness metrics, ablations that isolate a learned component, oracle and correctness validation, contamination-aware LLM handling, and provenance for mining.

Use when writing the related-work and positioning of an ASE (IEEE/ACM Automated Software Engineering) paper, covering the automated-SE literature lanes, delta-first positioning against prior tools/techniques, fair head-to-head framing, and double-anonymous self-citation.

Use when building the open-science and reproducibility story for an ASE (IEEE/ACM Automated Software Engineering) submission, covering the mandatory Data Availability Statement, anonymized-but-runnable tools, tool and subject-system provenance pinning, cached LLM outputs, and staging for the ACM Available/Reusable artifact badges.

Use when reasoning about how an ASE (IEEE/ACM Automated Software Engineering) research submission is evaluated, covering double-anonymous review, the early-rejection stage before rebuttal, the Accept / Revision / Reject outcomes, the criteria-bound revision round, and how ASE's process differs from FSE's PACMSE Major Revision, ICSE's cycles, and ISSTA's rounds.

Use when auditing an ASE (IEEE/ACM Automated Software Engineering) research-track submission for HotCRP readiness, covering the ACM acmart sigconf template and the 10+2 page budget, double-anonymous review, the mandatory Data Availability Statement, the early-rejection stage before rebuttal, and desk-reject triage before the deadline.

Use when deciding what belongs in the 10-page ASE (IEEE/ACM Automated Software Engineering) paper body versus the artifact and supplementary material, splitting content by decision-criticality so nothing that decides acceptance lives outside the reviewed pages under the 10+2 budget.

Use when deciding whether a software-engineering project belongs at ASE (IEEE/ACM Automated Software Engineering) or should be routed to ICSE, ESEC/FSE, ISSTA, a PL venue, or an SE journal, and when distinguishing ASE by its automation-centric contribution shape, its tool/technique emphasis, and its AI4SE/SE4AI scope.

Use when planning an ASE (IEEE/ACM Automated Software Engineering) research-track campaign backward from the deadline, through abstract registration, the double-anonymous submission, the early-rejection gate, rebuttal, the criteria-bound revision round, artifact evaluation, and the camera-ready in both IEEE Xplore and the ACM Digital Library.

Use when shaping the prose and structure of an ASE (IEEE/ACM Automated Software Engineering) research paper, covering the automation-first first-page arc, stating the automated task precisely, keeping the tool runnable and the model-swap test in mind, threats-as-argument, and the 10+2 page discipline on the ACM acmart template.

Use when preparing an ASPLOS artifact for the post-acceptance evaluation committee — writing the ae.tex Artifact Appendix with software/hardware/dataset dependencies, targeting the Available / Functional / Reproducible badges, archiving on a public repository, and planning the collaborative back-and-forth with evaluators.

Use when drafting an ASPLOS author response inside the short fixed window — triaging reviews into factual errors versus questions versus disagreements, budgeting for the ~800 words reviewers are expected to read, arguing only from evidence already in the submission, and positioning the paper for the Accept / Major Revision / Reject decision.

Use when converting an ASPLOS acceptance or Major Revision decision into a publishable ACM paper within the six-week window — de-anonymization, ACM rights and template obligations, the revision change note, artifact-appendix integration and badge placement, and Digital Library metadata checks.

Use when designing or auditing the evaluation of an ASPLOS paper — choosing among real silicon, FPGA prototypes, and simulators with cycle-accuracy caveats stated, selecting workload suites and baselines that hold up across three communities, attributing wins via ablation, and reporting energy, area, and overhead honestly.

Use when positioning an ASPLOS submission against three communities' literatures at once — covering the architecture, OS/systems, and PL/compiler lanes plus accelerator and prior-ASPLOS lines, handling own-work and arXiv material under the 2027 double-blind rules, and meeting the full-name/DOI citation format.

Use when hardening an ASPLOS paper's results for independent repetition — pinning simulator versions and configs, recording kernel/firmware/BIOS state, packaging FPGA bitstreams and RTL, documenting hardware dependencies an evaluator may lack, and writing availability statements that match what the ACM badges will later require.

Use when reasoning about how an ASPLOS submission will be judged — the two-page rapid-review screen and what it filters, full double-blind review, the author-response window, the Accept / Major Revision / Reject outcome set, how revisions are re-reviewed as submissions, and where authors actually hold leverage in each stage.

Use when running the final pre-upload audit of an ASPLOS submission — the 11-page limit covering figures/tables/footnotes with references excluded, the mandatory template, the no-"et al." full-name citation rule, hyperlinked DOIs, double-blind hygiene, GenAI disclosure, appendix self-containment, and HotCRP completion before the AoE deadline.

Use when deciding what goes into an ASPLOS submission's appendices versus the 11 self-contained pages — applying the rule that reviewers are neither required nor encouraged to read supplemental material, using anonymized supplements for unciteable own work, and staging content for the revision and artifact phases.

Use when deciding whether a project belongs at ASPLOS or at a single-community venue — applying the cross-layer deletion test, matching against ASPLOS's architecture/PL/OS intersection identity, routing to ISCA/MICRO/HPCA, PLDI/POPL, SOSP/OSDI/EuroSys, SC, or MLSys instead, and choosing between the April and September deadlines.

Use when planning an ASPLOS campaign across the two-deadline cycle — sequencing evidence building, the September 9, 2026 submission gate, author-response windows, the December 21 notification, Major Revision resubmission six weeks later, artifact evaluation, and the April 2027 conference in Crete, with owners per risk.

Use when drafting or revising ASPLOS prose — engineering the first two pages that rapid review actually reads, stating the cross-layer insight as one quotable sentence, structuring per-layer mechanism sections, writing bounded claims, and fitting everything into 11 self-contained pages that include figures and footnotes.

Use when packaging an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) artifact for the USENIX-lineage evaluation scheme — earning the Artifacts Available, Artifacts Functional, and Results Reproduced badges from the Artifact Evaluation Committee on its separate post-acceptance deadline, with evaluator-proof documentation and a turnkey path to the paper's numbers.

Use when writing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) rebuttal and the shepherd's description-of-changes — the short round-two response that corrects factual misreadings and supplies requested measurements, and the point-by-point revision record a conditional-acceptance shepherd checks before final acceptance.

Use when preparing the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) camera-ready after a conditional accept — de-anonymizing systematically, folding in the shepherd's required revisions, permanentizing artifact links, completing ACM Open Access metadata and the transition APC, and passing production checks for the November Hong Kong proceedings.

Use when designing or auditing the evaluation of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — matching evidence to the claim with real testbeds, fair baselines, end-to-end plus microbenchmark results, tail-latency and variance reporting, workload realism, and honest cost accounting.

Use when writing or auditing the related-work and positioning of an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — covering the systems literature lanes, positioning against OSDI/SOSP/NSDI/EuroSys/FAST, writing delta-first comparisons, and keeping self-citation double-blind.

Use when building the reproducibility story for an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — pinning testbed and software environments, providing a turnkey path from the artifact to the headline numbers, and preparing an anonymized-but-runnable review package ahead of the Available/Functional/Reproduced badges.

Use when reasoning about how an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) submission is evaluated — the two-round extended-abstract model, the round-one gate by two reviewers, the round-two read by 3-4 reviewers, double-blind reviewing, rebuttal, conditional acceptance with shepherding, and how ATC differs from OSDI/SOSP/NSDI.

Use when auditing an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) submission for HotCRP readiness — the paired two-page extended abstract plus full paper, the two-column 12/6-page budget, the double-blind anonymity sweep, ACM Open Access publication, and desk-reject triage before the early-June AoE cutoff.

Use when deciding what belongs in the ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) two-page extended abstract, the 12-page paper body, the optional appendix, and the artifact — splitting content by review round and decision-criticality so nothing that decides acceptance lives where a reviewer is not required to read.

Use when deciding whether a computer-systems project belongs at ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) or should be routed to OSDI, SOSP, NSDI, EuroSys, FAST, or a workshop like HotOS/HotStorage — distinguishing ATC by its broad practical scope, its Deployed Systems / experience lane, the breadth-vs-selectivity trade, and the November/June calendar.

Use when planning an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) campaign end to end — running the year backward from the early-June deadline through the two review rounds, the rebuttal, conditional-acceptance shepherding, the post-acceptance artifact evaluation, and the ACM Open Access camera-ready for the November Hong Kong conference.

Use when drafting or revising an ATC (ACM SIGOPS Annual Technical Conference, formerly USENIX ATC) systems paper — writing a self-standing two-page extended abstract for the round-one gate, structuring the implementation-and-measurement narrative, reporting costs beside gains, and holding the two-column 12-page budget.

Use when working with the Associate Editor and Editor of an Academy of Management Annals (Annals) review — scope alignment after a proposal is invited, what review-article referees evaluate, and revision expectations. Plans the interaction; it does not run the portal preflight (amann-submission) or draft the response letter (amann-revision).

Use when appraising the cumulative evidence and ensuring balance in an Academy of Management Annals (Annals) review — weighing conflicting findings by credibility, steelmanning rival schools, and handling the author's own work even-handedly. Audits evidence quality and fairness; it does not design the framework (amann-organizing-framework) or build exhibits (amann-tables-figures).

Use when systematically gathering, coding, and synthesizing a management/organization literature for an Academy of Management Annals (Annals) review — the search-and-coverage methodology and the choice of narrative vs. systematic vs. bibliometric integration. Builds the corpus and synthesis notes; it does not impose the organizing spine (amann-organizing-framework) or write prose.