paper-revise

Imported from zyx1121/plugin (skills/paper-revise/SKILL.md). Install upstream with npx skills add zyx1121/plugin --skill paper-revise. Copyright stays with the author.

/paper-revise — academic paper review checklist

收到 reviewer / 指導老師的意見後改 paper 用。IEEE / ACM conference 風格底色：動手前先用下面 10 條 self-audit，動完再對一次。

Reviewer 通常是 copy-editor + structural editor 混合：wording 精確、學術慣例、全文一致（含圖的視覺一致）是三大主軸；內容層面多用問句而非斷言（見 §9）。

Workflow

1. 抽 reviewer comments：PDF annotation 用 uvx pdfannots <pdf> 一次抽全部（highlight / sticky-note / strike-through）。抽出的文字與位置會失真（reading-order 重組）：句子可能亂序（看似 paper bug，其實原始 .tex 正確）、strikethrough 範圍跨錯字（看似 reviewer 自相矛盾）、極淡的標記可能漏看。判斷 reviewer 意圖前先 Read PDF 視覺頁面，以視覺標記為準。
2. 逐條 verdict：✓ 已 cover / ⚠ 部分 cover / ✗ 未 cover / N/A。
3. 依 10 條 checklist self-audit：reviewer 沒明示的同類問題往往散在其他段落。
4. 改完重編譯 LaTeX，確認頁數與 cross-ref 沒壞。
5. 回信條列改了什麼：分塊、跟 reviewer 原 comment 對齊、設計判斷附理由。只回應 reviewer 真正標的 comment；自己處理過程的 artifact（如 pdfannots 亂序句）不寫進回信，對方沒這個 context，講了只會困惑、還暴露內部流程。

1. 全文一致性（最大宗）

• 對比詞統一：「未改前的版本」整篇挑一個（existing / original / baseline / current）
• 設計版本詞統一：proposed / improved / new / revised 擇一
• Section / subsection heading 同型（全動名詞或全名詞短語）
• 縮寫定義格式全文同一種
• keyword list / index terms / category list 的順序規則一致

2. 縮寫

• IEEE Style Manual：首次出現用「全名 (縮寫)」
• Title / Abstract / 主文各區獨立看，不能假設「上面定義過」
• 同個縮寫不能在不同段落用兩種 expansion
• 全篇只出現一次就直接寫全名，不引入縮寫（例：Fixed Satellite Service (FSS) 之後再也沒出現 FSS，reviewer 會逐個抓）
• 首次出現可能藏在專名裡：AFC DUT Test Harness 的 DUT 就算首次出現，定義放這裡。專名無法用「全名 (縮寫)」時改用「縮寫 (全名)」變通（AFC DUT (device under test) Test Harness），後面再用縮寫

3. 學術寫作慣例

• 口語詞換正式詞（lab → laboratory）
• 弱動詞換強動詞（address → overcome / tackle / resolve）
• 沒語境的 actual / real-world 拿掉
• 避免被動式自我指涉（is reported / are presented：研究自己 report 給自己看？）
• Introduction 結尾要有 "The remainder of this paper is organized as follows…"
• Reference 按文中首次出現順序排
• 不能全是 standards / vendor / regulator docs，要有 peer-reviewed paper

4. 反模糊指代

• the X 沒指明哪個時補形容詞（the proposed X / the existing X）
• 縮寫式 / 暗示式表達（如 update by edit）要展開
• X that follows：follows 什麼、哪個 section，要交代

5. 內容分層

• Abstract 砍枝節：數據、列表、廠牌挪後文，不要 (A, B, C, D) 在 abstract
• Caption 一句概括，細節寫在 prose
• 長句用句號拆，避免 ; in parallel / ; on the other hand 連接

6. 結構引導

• Section 開頭有「we propose X to Y」/「this section presents Z」
• Background 預告後面要動的元件（讓讀者提早抓到 paper 攻擊面）
• 純括號圖表 reference（(Fig. 1)）IEEE 少見，改 As illustrated in Fig. 1, ...

7. over-specificity / over-claim

• 廠牌 / 工具 / 實作細節不寫進 contribution claim；例子可以 specific（e.g., XXX），claim 要抽象
• 圖與圖之間的共同元件要長一樣，免得讀者以為同一個東西變了

8. 前後呼應 / 重複

• Title 跟 Conclusion 呼應；Conclusion 用「測 X 驗證 Y、測 Z 證明 W」對應 contribution
• 同份資訊不重複出現（caption vs 內文、abstract vs conclusion）

9. Reviewer 的問句 vs 斷言

• 問句（「這邊是不是該用 X？」「這個詞想表達什麼？」）是 reviewer 不想 dictate、要 author 自己判斷，不是她不確定。對策：評估選項後挑一個 + 給理由，不能無視。
• 設計判斷型問題（圖該不該改、Section 該不該重排）：「保留 + 內文加一句 disambig」通常比動圖或動架構便宜且精準。
• 斷言式的字面替換（X → Y）要先驗語法。照字面套可能出錯：With the opening of → To open 主詞錯位；刪定冠詞 the 不合文法。抓底層意圖（去名詞化、減冗字），用語法正確的方式達成（改寫句子，或用所有格 WFA's 取代 the）。
• reviewer 要外觀一致時可能跟專名大寫 / hyphen 規則衝突：選破壞最小的方向統一（複合形容詞去 hyphen DUT-side → DUT side 比給名詞片語加 hyphen 自然；流程圖 node 全用 sentence case），不要為了跟她解釋規則而抗拒統一。

10. 不把 extension 寫成 generality

Contribution 講「extensible / vendor-neutral / any X」但只 demo 一個 X，reviewer 會抓 N=1。

• 要嘛收 claim（validated on one instrument），要嘛 frame 成「provide the extension point + reference implementation」而不是「prove generality」
• Abstract 與 Conclusion 收 claim 要對稱，一邊改一邊不改會被抓頭尾不一致
• N=1 / 過 claim 是高風險區，提早收比硬撐安全

Anti-pattern

• 把 reviewer comment 當逐條 to-do 做完就收，漏掉散在別處的同類問題
• 改到 overflow（例如 5 頁上限）：改完重編譯驗頁數；真的 overflow 時，從 reviewer 也要求精簡的地方收字（如 conclusion 重複 eval 數據）+ §5，不砍 reviewer 要求新增的實質內容
• 為了處理 comment 加入 paper 框架外的新概念，等於給下一輪 reviewer 新的 attack surface
• 用 generic reviewer agent 做 cross-check 卻沒限定範圍，它會用 top-tier venue 標準抓出超出 reviewer scope 的新問題。prompt 要寫明「只 verify 對齊原 comments，不擴展 scope」