Agent Skills
› brycewang-stanford/Awesome-Journal-Skills
› podc-related-work
podc-related-work
GitHub指导撰写ACM PODC论文相关工作部分，强调在分布式计算理论中基于模型、问题及界值进行精确对比。涵盖文献渠道选择、明确贡献增量（Delta）、区分模型差异，并遵守双盲评审规范，避免无效综述。
Trigger Scenarios
撰写PODC论文的相关工作章节
需要对比分布式计算领域的算法界值与模型
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill podc-related-work -g -y
SKILL.md
Frontmatter
{
"name": "podc-related-work",
"description": "Use when writing the related-work and positioning of an ACM PODC paper — covering the distributed-computing literature lanes (PODC\/DISC\/SPAA and the JACM \/ Distributed Computing journals), writing a model-and-bound-precise delta over prior results, distinguishing your model from neighboring ones, and keeping self-citation safe under lightweight double-blind review."
}
PODC Related Work
Position against results, not topics. In distributed-computing theory a "related" paper is one that proves a bound in a comparable model, and your delta must be stated in the currency the field uses: model + problem + cost measure + bound. A related-work section that lists topics ("several works study consensus") without the bounds and models tells a PODC reviewer nothing.
The literature lanes
- PODC and DISC — the two distributed-theory flagships; most of your closest prior bounds live here. They share the Dijkstra Prize and Dissertation Award and much of a reviewer pool, so their results are the ones your reviewers know best.
- SPAA — parallel algorithms/architectures; relevant for shared-memory and concurrency results, less so for message-passing/fault-tolerance.
- STOC / FOCS / SODA — where a distributed result's sequential core or a key combinatorial lemma may have appeared; cite when your technique descends from sequential theory.
- Journals — JACM and Distributed Computing — the archival, definitive versions of many results (FLP, partial synchrony, linearizability). Cite the journal version for the canonical statement, and the conference version if you specifically mean that edition.
- Focused venues — OPODIS, SIROCCO, SSS, ICDCN — for niche models (mobile agents, networks, self-stabilization).
- Systems venues / arXiv — for applied or very recent work; cite carefully and note when a result is empirical rather than proved.
Write the delta in the field's currency
For each closest prior result, state the comparison precisely:
[Prior] <authors, venue/year>: <problem> in <model>, <bound> (e.g., O(n^2) messages, t < n/2, synchronous)
[Ours] same problem in <model>: <bound> (e.g., O(n log n) messages, t < n/3, partial synchrony)
[Delta] what improved and at what cost: better message complexity but weaker resilience / stronger
adversary / different timing model — state the trade honestly
The discipline is to make model differences explicit. "We improve on [X]" is misleading if [X] was synchronous and you are asynchronous, or if [X] tolerated more faults. A PODC reviewer will notice an apples-to-oranges comparison immediately, and it reads as either sloppiness or spin.
Distinguish your model from neighbors
Much apparent overlap dissolves once models are pinned down. Make sure the reader cannot confuse your setting with an adjacent one:
- Synchrony: a bound under synchrony does not contradict a lower bound under asynchrony.
- Fault model: crash-tolerant and Byzantine-tolerant results are not comparable head-to-head.
- Adversary: adaptive vs. oblivious changes what is achievable; say which you assume.
- Cost measure: a round-optimal protocol may be message-suboptimal; name the measure you optimize and acknowledge the others.
Positioning your contribution
- Delta-first: open the related-work discussion (or the introduction's positioning paragraph) with what is new relative to the nearest result, not with a history of the problem.
- Concede honestly: if a prior protocol beats you on one measure while you beat it on another, say so. A trade-off stated plainly is a stronger paper than an overclaimed strict improvement.
- Locate the lower bound: if your algorithm is optimal, cite (or prove) the matching lower bound and say which prior lower bound your result meets or circumvents (by changing the model).
Self-citation under lightweight double-blind
PODC 2026 is lightweight double-blind, so self-citations must not de-anonymize you:
- Refer to your own prior work in the third person: "Prior work [12] shows..." never "In our earlier paper [12] we show...".
- Do not write "as we proved in [12]" or "extending our framework [7]".
- Keep the citation itself in the bibliography (do not remove it — that distorts the record); just neutralize the phrasing that reveals authorship.
- Watch for indirect leaks: "building on the model of [our group's] system X" or an acknowledgement of a grant tied to you.
Common failures
- Topic lists instead of bound comparisons — no models, no complexities, no delta.
- Apples-to-oranges "improvements" — comparing across incompatible synchrony/fault/adversary assumptions without flagging it.
- Missing the closest result — a reviewer who works in your subarea knows the one paper you did not cite; that omission reads as either ignorance or evasion.
- Journal-vs-conference confusion — citing a PODC edition for a result whose canonical statement is a JACM article (or vice versa); see the exemplars library's omissions list.
- Self-citation leak — first-person references to your own prior work under double-blind.
Output format
[Lanes covered] PODC/DISC/SPAA/STOC-FOCS-SODA/journals/focused venues — each relevant one present?
[Delta table] for each closest prior result: model, bound, ours, honest trade-off
[Model distinctions] synchrony/faults/adversary/cost-measure differences made explicit?
[Optimality] matching lower bound located/cited/proved?
[Double-blind] self-citations third-person; no grant/group leaks?
[Fix queue] <missing closest results; over/under-claimed deltas; leaks to fix>
Version History
- 9f86f09 Current 2026-07-19 17:16
