fast-review-process
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.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill fast-review-process --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# FAST Review Process Model the pipeline before interpreting any single review. FAST — the USENIX Conference on File and Storage Technologies — uses the USENIX systems-review machinery: **double-blind** program-committee review, an **author-response** period, PC **shepherding** for accepted papers, and a **one-shot revision** track. The most consequential mental shift for authors is understanding that FAST has *four* outcomes, not two, and that a one-shot revision is a real, bounded second chance — not a soft accept and not an open-ended journal R&R. ## Process model - Submission and review run on **HotCRP** (a separate instance per deadline) with **double-blind** anonymity: identities are hidden from reviewers; authors anonymize the PDF and references and refer to their own prior work in the third person. - The **program committee** reviews, assisted by **outside referees** when needed. Storage papers are matched to reviewers from their subarea (file systems, SSD/NVM, KV stores, caching, reliability), so device details and evaluation state are scrutinized, not skimmed. - There is an **author-response (rebuttal) period** before notification: a short window to answer reviewer questi
- Process model
- Reading a decision against the categories
- What a one-shot revision actually is
- How FAST differs from its siblings
- Who reads you
- Where author leverage actually exists
- Misreadings to avoid
- Output format
What does the fast-review-process skill do?
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.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill fast-review-process --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From brycewang-stanford/Awesome-Journal-Skills, a repository with 909 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.