Claude Skills by brycewang-stanford

Use when writing the response to a British Journal of Political Science (BJPS) revise-and-resubmit. The response must convert each of the (usually two-plus) double-blind referees while keeping the editor confident the revision is convergent. Structures the response letter; it does not fabricate new results.

Use when defending the research design of a British Journal of Political Science (BJPS) manuscript — causal identification for quantitative work, case selection and process tracing for qualitative work, experimental and survey-experimental design, or formal-empirical linkage. BJPS judges each tradition on its own terms. Strengthens the design; it does not write code.

Use to understand how the British Journal of Political Science (BJPS) evaluates a manuscript — double-blind review with at least two referees, the desk screen, decision categories, and what reviewers are asked to weigh. Sets expectations and shapes the paper to survive review; it does not contact editors.

Use when running the final pre-submission preflight for the British Journal of Political Science (BJPS) — format selection, double-blind anonymization, word/abstract caps, Cambridge (Harvard author-date) house style, ORCID, and declarations. Final checks; it does not draft content.

Use when building tables and figures for a British Journal of Political Science (BJPS) manuscript so exhibits are self-contained, accessible, fit Cambridge's size limits, and earn their place under the word budget. Designs exhibits; it does not run the analysis.

Use when building the theoretical argument of a British Journal of Political Science (BJPS) manuscript into a contribution of general interest — whether the work is formal/game-theoretic, empirical with explicit mechanisms, interpretive, or normative. BJPS rewards a clear, portable argument over a bare finding. Structures the argument; it does not run analyses.

Use when deciding whether a political-science project fits the British Journal of Political Science (BJPS) and which of its three formats to target. BJPS is a broad, internationally-oriented general journal, so the test is wide interest across subfields and beyond one national case, not subfield novelty alone. Helps frame the question; it does not collect data.

Use when preparing the replication / transparency materials for a British Journal of Political Science (BJPS) manuscript. BJPS is a DA-RT signatory and requires authors to deposit replication data and code in the BJPolS Dataverse (Harvard Dataverse) at acceptance, with restricted-access exemptions. Covers quantitative and qualitative transparency. Prepares the package; it does not waive requirements.

Use as the entry point for any British Journal of Political Science (BJPS / BJPolS) manuscript. Routes to the right BJPS sub-skill based on lifecycle stage and which of the three formats (Research Article, Letter, Comment) fits. It dispatches; it does not draft content.

Use when drafting or polishing a British Journal of Political Science (BJPS) manuscript so it reads for a broad, international political-science audience, follows Cambridge's house (Harvard author-date) style, and fits the word caps (Research Articles ~10,000 words; Letters ~4,000; abstract <= 150 words). Tightens prose and format; it does not invent content.

Use when packaging a CAV (Computer Aided Verification) artifact for the Artifact Evaluation Committee (AEC), covering the three badges (Available / Functional / Reusable), the smoke-test and full-review phases, ≥2 AEC reviewers per artifact, DOI-issuing archives, verification-tool packaging (solvers, benchmarks, seeds, resource limits, proof witnesses), and the fact that AE is invited, post-notification, and non-conditional.

Use when drafting a CAV (Computer Aided Verification) author response (rebuttal) for a paper that has passed the two-stage review's first filter, covering how to answer soundness/proof objections, benchmark-fairness challenges, and novelty-delta doubts with verifiable evidence while preserving double-anonymity for Regular and Application papers.

Use when preparing an accepted CAV (Computer Aided Verification) paper for its Springer LNCS open-access camera-ready, covering de-anonymization for the previously double-blind categories, the LNCS llncs template and Springer metadata (ORCID, author order, running heads), the copyright/open-access forms, integrating reviewer-required changes without scope creep, permanentizing artifact links, and the AEC badge handoff.

Use when designing or auditing a CAV (Computer Aided Verification) empirical evaluation, covering standard benchmark sets (SV-COMP/SMT-COMP/HWMCC/VNN-COMP), fair baseline solvers with pinned versions and equal resource limits, timeout-dominated comparisons, soundness cross-checks and proof witnesses, cactus/scatter reporting, and matching evidence to the shape of each verification claim.

Use when positioning a CAV (Computer Aided Verification) submission against the verification literature across CAV, TACAS, FMCAD, VMCAI, POPL/PLDI, and the journals (FMSD, JAR, TOCL, STTT), writing delta-first contrast rather than a citation catalog, crediting the right benchmark and tool lineages, keeping self-citations double-anonymous for the anonymized categories, and handling concurrent and prior-version overlap.

Use when strengthening CAV (Computer Aided Verification) reproducibility, covering benchmark provenance (SV-COMP/SMT-COMP/HWMCC/VNN-COMP set revisions), pinned tool and baseline versions, resource limits and hardware, seeds for randomized/portfolio solvers, checkable proof witnesses/certificates for soundness claims, and consistency between the paper's tables and the artifact.

Use when reasoning about how a CAV (Computer Aided Verification) submission is evaluated, covering the two-stage reviewing process (two reviews then an early-reject filter, then two more reviews with a rebuttal), the partial double-anonymity by category, the accept/reject outcome, the optional non-conditional artifact evaluation, and how CAV differs from TACAS and FMCAD.

Use when auditing a CAV (Computer Aided Verification) submission for portal readiness, covering the four submission categories (Regular / Short Tool / Short Application / Industrial Experience & Case Studies), the LNCS page limits, the per-category anonymization matrix, the artifact-intent declaration, and desk-reject triage before the AoE paper deadline.

Use when deciding what belongs in a CAV (Computer Aided Verification) paper body versus its optional appendix and artifact, covering the LNCS page limits, the rule that reviewers are not obliged to read the appendix so decision-critical content stays in the body, where full proofs and benchmark tables live, and double-anonymous supplementary material for the anonymized categories.

Use when deciding whether a formal-methods project belongs at CAV (Computer Aided Verification) or should be routed to TACAS, FMCAD, VMCAI, LPAR/IJCAR, POPL/PLDI/OOPSLA, or a journal (FMSD/JAR/TOCL), and when choosing the right CAV category — Regular, Short Tool, Short Application, or Industrial Experience & Case Study.

Use when planning a CAV (Computer Aided Verification) project timeline from venue and category selection through submission, the two-stage review with early reject and rebuttal, artifact evaluation by the AEC, and the LNCS open-access camera-ready, with backward-planning offsets for a verification-tool paper and honest handling of the single-annual-deadline cycle.

Use when revising a CAV (Computer Aided Verification) paper for a precise verification contribution on the first page, an explicit soundness/completeness statement, theorem-and-proof discipline in the LNCS page budget, fair benchmark claims, honest scope and limits, and double-blind wording for the anonymized categories.

Use when packaging the artifacts behind an ACM CHI paper — prototypes, study instruments, codebooks, datasets, analysis code — for anonymous review scrutiny and for post-acceptance archival release, in a venue with no formal artifact-evaluation committee doing it for you.

Use when an ACM CHI paper receives a revise-and-resubmit invitation and the five-week window opens — planning the revision triage, making tracked changes reviewers can audit, and writing the response letter that carries the paper through round 2 and the PC meeting.

Use when preparing an accepted ACM CHI paper for publication — the TAPS source upload, the PCS publication-ready package, mandatory accessibility work (alt text, screen-reader-friendly PDFs, table headers), video previews, ACM's open-access model, e-rights, and registration deadlines.

Use when designing or auditing the studies behind an ACM CHI paper — matching evidence shape to contribution type, powering quantitative experiments, making qualitative work rigorous and auditable, reporting participants and ethics properly, and avoiding the ADR-Data and ADR-Method screening grounds.

Use when building the related-work section of an ACM CHI paper — covering the HCI venue family and the non-CS disciplines CHI draws on, positioning against the last few CHI cycles, keeping self-citation anonymous — in a venue where insufficient contextualization is the top assisted desk-reject ground.

Use when strengthening research transparency for an ACM CHI paper — protocols, instruments, codebooks, analysis scripts, preregistration, and data availability under human-subjects constraints — so methods survive the ADR-Method screening and others can actually build on the work.

Use when interpreting the ACM CHI Papers review pipeline — 1AC and 2AC roles, the A/ARR/RR/RRX/X recommendation scale, desk-reject and rubric-based assisted desk-reject screening, the revise-and-resubmit threshold, round-2 PC decisions — and what each stage means for authors.

Use when auditing an ACM CHI Papers submission for PCS readiness, covering the September full-paper deadline, the anonymized single-column template, word-count norms instead of page limits, subcommittee designation, supplementary and video upload, anonymization of external links, and CHI's desk-reject triage before upload.

Use when assembling supplementary materials for an ACM CHI submission — the video figure with mandatory closed captions, appendices, study instruments, code and data archives — all due with the paper on the single September deadline, anonymized end to end, plus the camera-ready video preview.

Use when deciding whether a project belongs at ACM CHI, which of CHI's contribution types it makes, and which reviewing subcommittee should judge it — or whether the work is better routed to UIST, CSCW, DIS, IUI, ASSETS, IMWUT, or TOCHI before any drafting starts.

Use when planning an ACM CHI submission cycle end to end — the single September deadline, two-round review with a five-week revise-and-resubmit window, December decisions, the TAPS and publication-ready chain, and the May conference — with owners and risk buffers for each stage.

Use when drafting or revising the prose of an ACM CHI paper — contribution statements, structure for mixed reviewer audiences, participant voice, calibrated claims, accessible and bias-free writing, and length discipline in a venue that reviews words against contribution instead of pages.

Use when packaging the code, datasets, knowledge graphs, prompts, and demo systems around a CIKM paper — choosing the artifact form per track (research, applied, resource, demo), meeting the resource track's reuse-and-documentation bar, and staging anonymous review artifacts into citable public releases.

Use when preparing author-side communication around CIKM reviews — drafting for a response window if the cycle offers one (unconfirmed for 2026), writing camera-ready revision notes that answer reviewer concerns, handling post-decision chair correspondence, and converting rejection reviews into a resubmission brief.

Use when turning an accepted CIKM paper into its ACM proceedings version inside the short notification-to-camera-ready window, covering de-anonymization, the e-rights and TAPS pipeline into the ACM Digital Library, CCS concepts and metadata, GenAI-disclosure retention, artifact link publication, and Rome presentation logistics.

Use when designing or auditing the empirical program of a CIKM paper — matching evidence to the claim's lanes across retrieval, mining, and knowledge-management evaluation cultures, choosing datasets and baselines that survive a blended panel, isolating the boundary mechanism, and meeting applied-track deployment-evidence bars.

Use when positioning a CIKM submission against three literatures at once — retrieval, mining, and knowledge management/databases — building the boundary-work paragraph, guarding against misattributing SIGIR/KDD/ICDM classics to CIKM, and handling preprints under the arXiv-declaration and dual-submission rules.

Use when hardening the reproducibility of a CIKM paper — pinning the pipeline stages where IR, mining, and knowledge-management results silently diverge, documenting KGs and enterprise data that cannot be released, keeping the GenAI disclosure consistent with how code and data were produced, and preparing the post-acceptance release.

Use when reasoning about CIKM peer review — the EasyChair double-blind pipeline, the mixed IR/data-mining/knowledge-management reviewer pool, per-track evaluation criteria, the ACM Peer Review Policy including the no-AI-written-reviews rule, notification timing, and what actually moves borderline decisions.

Use when auditing a CIKM submission for EasyChair readiness across the five tracks, covering page budgets with appendices counted inside, the mandatory GenAI Usage Disclosure section, author-reviewer nomination, double-blind rules with arXiv declaration, the abstract-gate authorship freeze, and desk-reject triggers.

Use when deciding what supporting material accompanies a CIKM submission given budgets that count appendices inside the page limit, structuring the in-PDF appendix versus the anonymously cited artifact, keeping both double-blind, and handling the uncounted GenAI-disclosure and reference sections correctly.

Use when deciding whether a project fits CIKM, the tri-community ACM venue spanning information retrieval, data mining, and knowledge management/databases, when weighing CIKM against SIGIR, KDD, WSDM, TheWebConf, SIGMOD/VLDB, or ISWC, and when choosing among CIKM's five tracks before writing begins.

Use when planning a CIKM project calendar across the May abstract/paper gates, June short-track gates, August notification and camera-ready, and the November conference, including the post-submission phase now live in the 2026 cycle, multi-track coordination, and fallback planning toward CIKM 2027 or sibling venues.

Use when revising a CIKM manuscript for the tri-community readership — writing an opening that lands with IR, data-mining, and knowledge-management reviewers simultaneously, compressing into appendix-inclusive page budgets, keeping claims inside the evidence, and maintaining double-blind and disclosure-compliant prose.

Use when packaging the artifacts of a COLM paper — model weights, training data, prompts, evaluation sets, and cached model outputs — for anonymous review and public post-acceptance release, navigating licenses, API terms-of-service limits, and the absence of a formal COLM artifact track.

Use when writing a COLM rebuttal in the OpenReview discussion phase — triaging reviews released in late May, running cache-based follow-up experiments inside the roughly two-and-a-half-week window, answering contamination and baseline-fairness objections with evidence, and writing for the area chair who decides in July.

Use when converting a COLM acceptance into the final paper — the August 7 camera-ready deadline in 2026, de-anonymization and the one-page acknowledgments allowance, folding rebuttal commitments into the text, publishing on OpenReview, releasing artifacts publicly, and planning the October conference in San Francisco.

Use when designing or auditing the empirical core of a COLM paper — contamination analysis for evaluation data, fair baselines under matched prompting and compute, pinned model versions and decoding parameters, uncertainty over runs and samples, scaling coverage, and honest reporting of API-model comparisons.