FAST Skills

A 12-skill depth pack for USENIX FAST (the USENIX Conference on File and Storage Technologies): routing a storage paper among FAST and its siblings (OSDI/ATC/NSDI/EuroSys/HotStorage/MSST/ACM TOS), the two-deadline (Spring/Fall) HotCRP cycle with USENIX double-blind review, the one-shot-revision decision, storage-specific evaluation (workload traces, write amplification, endurance/wear, tail latenc

by @brycewang-stanford 10 skills

Install

npx skillmds@latest add plugin:brycewang-stanford/fast-skills

One command, no setup. In Claude Code it lands as a managed plugin you can enable, disable or remove with /plugin. On any other agent it installs the 10 skills into that agent's own folder.

Or inside Claude Code

In the Plugins tab, add this marketplace:

skillmds/skillmd
/plugin install brycewang-stanford-fast-skills@skillmd

Adds the marketplace once; later plugins need the second line only.

Or install by hand

Download the plugin and unzip its skills/ folder into your agent's skills directory. Works with every agent, no CLI needed.

Download plugin Paths per agent

Just the markdown? SKILL.md files only.

This plugin

skills: 10
authors: 1

Published by a registry member. Review its skills before installing.

Skills in this plugin

▌
Fast Submission · brycewang-stanford
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.

1k repo stars
▌
Fast Experiments · brycewang-stanford
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.

1k repo stars
▌
Fast Camera Ready · brycewang-stanford
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.

1k repo stars
▌
Fast Supplementary · brycewang-stanford
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.

1k repo stars
▌
Fast Writing Style · brycewang-stanford
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.

1k repo stars
▌
Fast Review Process · brycewang-stanford
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.

1k repo stars
▌
Fast Author Response · brycewang-stanford
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.

1k repo stars
▌
Fast Reproducibility · brycewang-stanford
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.

1k repo stars
▌
Fast Topic Selection · brycewang-stanford
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.

1k repo stars
▌
Fast Artifact Evaluation · brycewang-stanford
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.

1k repo stars