oopsla-writing-style
GitHub指导将草稿改写为OOPSLA论文风格，强调可验证性、设计洞察前置、具体示例驱动及严谨的局限性陈述。提供语气校准、结构安排和23页篇幅规划建议，以优化审稿结果并减少修改需求。
触发场景
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill oopsla-writing-style -g -y
SKILL.md
Frontmatter
{
"name": "oopsla-writing-style",
"description": "Use when revising a draft into OOPSLA's register — design insight stated before the artifact, claims written to be falsifiable, motivating examples that carry semantics, journal-article pacing inside the 23-page cap, and honest threats-to-validity prose that preempts the revision lever rather than triggering it."
}
OOPSLA Writing Style
An OOPSLA paper is read twice by design: once by a committee choosing among four outcomes, and again — possibly by the same people — if a revision comes back. Style at this venue therefore optimizes for checkability: a paper whose claims can be verified paragraph by paragraph collects bounded revision demands (or none), while a paper that argues by adjective collects unbounded ones. The published form is a journal article (PACMPL), and the prose should carry that register: measured, self-contained, built to be cited.
Voice calibration
| Draft habit | OOPSLA replacement |
|---|---|
| "We present NovelTool, a novel system for..." | Name the design question and your answer; the tool arrives as evidence (see resources/worked-examples/01-introduction.md) |
| "Our approach significantly outperforms..." | The number, the baseline, the workload, the dispersion — or nothing |
| "To the best of our knowledge, first..." | A positioning sentence naming the nearest prior work and the delta (oopsla-related-work) |
| "Due to space limitations, details are in the appendix" | A body-level statement of what the appendix establishes (oopsla-supplementary) |
| A wall of formalism before any example | A running example that motivates each definition as it appears |
The running example as load-bearing structure
OOPSLA's classic papers — from type-system counterexamples to
language-experience reports (resources/exemplars/library.md) — are built
around concrete programs. Choose one small example early and make it do
three jobs: expose the problem, exercise the mechanism, and mark the
boundary (show the case the mechanism does not handle). If your example
cannot demonstrate the limitation honestly, the limitation section will read
as boilerplate — reviewers notice.
Claims that survive two readings
Write each contribution as a sentence with a built-in test:
Weak: "We propose an efficient analysis for X."
Strong: "The analysis decides X for programs in fragment F in O(n log n);
outside F it degrades to a sound approximation, evaluated in §6.3."
Weak: "Our semantics is more expressive."
Strong: "Every program typable under [prior] remains typable (Thm 4.1);
the converse fails on the example of §2.2."
The strong forms give a Minor-Revision reviewer something bounded to check — which is exactly the outcome ladder you want to be standing on.
Journal pacing inside 23 pages
- Spend the first two pages entirely on problem, insight, and claims; a reader stopping there should be able to state your thesis.
- Sections should alternate mechanism and evidence; ten pages of design followed by two of evaluation reads as unvalidated, the inverse as unmotivated.
- Threats-to-validity and limitations get their own subsection with specific content: which claims depend on which assumptions, and what was not measured. Generic threats paragraphs are revision bait.
- Prose must not lean on the appendix for coherence; the 23 pages are the
paper (
oopsla-supplementaryfor the layering rule).
Revision-aware editing
When revising for a second round, mark the diff in prose quality too: the change log tells reviewers where you changed; the writing must make each change locally self-justifying, because continuity means your examiners remember the old text. Never quietly weaken a claim a reviewer challenged — weaken it visibly, with the reason.
Output format
[Register] design-insight-led: yes/no + first page diagnosis
[Adjective sweep] unquantified evaluatives found: <count + worst three>
[Claim audit] contributions rewritten in falsifiable form
[Example] running example present / missing / does not mark boundaries
[Pacing] mechanism-evidence alternation + limitations specificity
版本历史
- 9f86f09 当前 2026-07-19 17:10
