Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› vldb-writing-style
vldb-writing-style
GitHub用于PVLDB论文修订，确保首段明确工作负载、设计决策与测量结果；要求量化性能主张并限定范围；强调坦诚陈述设计权衡；规范术语一致性；提供自查清单以提升系统类论文的清晰度与可信度。
Trigger Scenarios
需要修改或润色VLDB系统类论文的行文风格
检查性能声明是否缺乏具体数据支撑
审查论文是否隐藏了设计带来的成本或权衡
统一全文术语命名以避免混淆
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill vldb-writing-style -g -y
SKILL.md
Frontmatter
{
"name": "vldb-writing-style",
"description": "Use when revising a PVLDB paper's prose, covering the page-one contract for systems readers, scoping performance claims to measured regimes, stating design trade-offs instead of hiding them, terminology and notation discipline across a 12-page budget, and the tone VLDB's builder-reviewers reward."
}
VLDB Writing Style
Use this during revision passes. The PVLDB reader is a systems builder deciding, inside the first page, whether your design decision is worth their evening. Style at this venue is not ornament — it is claim hygiene.
The page-one contract
By the end of page one the reader must know:
- The workload that breaks current systems — concrete, not "growing data volumes."
- The design decision — the bet your system makes that others do not.
- What was built — real system, extension of a named engine, or simulation; readers calibrate trust to this immediately.
- The headline measurement, scoped — metric, scale, baseline, hardware class, all in one sentence.
A running example introduced early and reused through design and evaluation sections is the genre's most effective device; pick one query, one tenant, one failure trace and let it carry the mechanism.
Claim scoping table
| Unscoped (review bait) | Scoped (survives) |
|---|---|
| "significantly faster than X" | "2.1x median speedup over X (v3.4, tuned per §6.1) on workload W at 1TB" |
| "scales to large clusters" | "near-linear to 64 nodes; efficiency drops to 71% at 128 (Fig. 9)" |
| "negligible overhead" | "adds 3-5% CPU on write-heavy YCSB-A; worst case 11% at 99% writes" |
| "state-of-the-art performance" | delete; name the systems and the regime |
Every superlative either gains a number, a workload, and a baseline — or dies.
Trade-off candor
Systems reviewers assume every design pays somewhere. A paper that never says what its mechanism costs reads as unmeasured, not as flawless.
- State the price of the design in the introduction (memory, write path latency, generality) and point to the section that measures it.
- Put the loss cases in the main evaluation, not a footnote: the workload where the baseline wins is your credibility purchase.
- Prefer "we chose A over B because C, accepting cost D" over passive descriptions that hide the decision.
Budget and terminology discipline
- One name per concept for all 12 pages: a "segment" on page 3 cannot become a "chunk" on page 9. Builder-readers parse terminology as architecture.
- Architecture figure by page 3; reviewers reconstruct systems visually.
- Since references are uncapped but appendices are not, spend prose on mechanism and measurement, and let citations carry the history compactly.
- Single-blind means writing "we extend our earlier system [12]" is fine — clarity about lineage beats coy third-person contortions.
Self-edit sweep
grep-worthy passes before submission:
"significant" -> replace with the number or delete
"novel" -> the contribution list should prove it instead
"to the best of our knowledge" -> keep at most one, verified
"very large" -> state the size
passive "was designed" -> name the decision and its reason
every Figure N -> referenced in text, at least one sentence of reading
Output format
[Page-one contract] met / missing elements listed
[Unscoped claims] <count, worst three quoted>
[Trade-off candor] price stated in intro? loss cases in eval?
[Terminology drift] <concept -> competing names found>
[Running example] present / absent (suggested candidate)
[Edit order] <highest-leverage rewrites first>
Version History
- 9f86f09 Current 2026-07-19 17:53
