initial commit

skills/research-paper-reviewer.md

@@ -0,0 +1,129 @@
+# Research Paper Reviewer
+
+用于审查计算机系统方向论文、proposal、技术报告或单个 section。默认不做全面泛审；用户应声明 review purpose。未声明时，先问 purpose。
+
+## Supported Purposes
+
+| Purpose | 回答的问题 |
+|---|---|
+| `thesis-clarity` | 核心论点是否一句话说得清？ |
+| `problem-importance` | problem 是否真实、重要、端到端相关？ |
+| `derivation-and-evidence` | 推导是否符合第一性原理，证据是否支撑 claim？ |
+| `novelty` | 与已有工作相比，差异是否真实且足够？ |
+| `simplicity` | 方法是否过度设计？ |
+| `writing-kaashoek-style` | 写作是否短、直接、先结论后理由？ |
+| `typos-and-references` | 是否有明显 typo、引用或交叉引用问题？ |
+
+可组合多个 purpose，例如 `problem-importance + novelty`。按顺序分别输出。
+
+## Output
+
+```md
+Purpose: <name>
+Findings:
+- [Blocking | Major | Minor] <结论> — callback: <论文具体位置或应处理但未处理的相关工作>
+Suggested revision: <可直接执行的修改；没有则写 none>
+```
+
+## Purpose: thesis-clarity
+
+判断论文是否能被概括为：
+
+> 本文提出 X，在 topic 中解决一个重要 problem，相比 baseline/SOTA 改善 metric，因为 reason。
+
+检查：
+
+- 是否能从 abstract/intro 抽出 X、topic、problem、baseline/SOTA、metric、reason。
+- X 是否真的针对该 problem。
+- 是否在讲清 problem 前过早讲 solution。
+- research question 是否具体，而不是“提升性能/效率/准确率”。
+
+任一核心要素缺失，默认 `Blocking`。
+
+## Purpose: problem-importance
+
+检查：
+
+- topic 是否具体，而不是过大的领域标签。
+- problem 是否真实存在于实际系统、工作负载或资源约束中。
+- 没有解决该 problem 会造成什么实际后果。
+- problem 是否是端到端 bottleneck，还是只优化占比极小的组件。
+- metric 是否真正量化了该 problem。
+- 影响范围是否足够：系统、应用、用户、工作负载、部署场景。
+
+## Purpose: derivation-and-evidence
+
+检查 claim -> reason -> evidence -> warrant 链条。
+
+### Claim
+
+- 核心 claim 是性能、成本、可扩展性、可靠性、可用性，还是机制理解。
+- claim 是否明确写出，而不是让 reviewer 猜。
+
+### Reason
+
+- 为什么认为 claim 成立。
+- 关键 reasons 是否独立，是否偷换概念。
+- 让 solution work 的关键 technique 和 assumption 是否被明确写出。
+
+### Evidence
+
+- 实验假设是否清楚，是否接近真实环境。
+- baseline 是否足够强，比较是否公平。
+- 是否覆盖不同配置、规模、工作负载。
+- 指标是否对应 problem。
+- 结果是否稳定，而非只展示 best case。
+- 是否有 ablation 证明收益来自核心技术。
+- 是否有 sensitivity 说明何时成立、何时失效。
+
+### Warrant
+
+- evidence 到 claim 的推理是否完整。
+- 是否把观察到的结果写成机制解释。
+- 是否把部分 benchmark 成立写成普遍成立。
+- 是否排除替代解释：调参、实现差异、配置差异、benchmark 偏置。
+
+审阅单个非 intro/abstract section 时，默认只跑此 purpose。
+
+## Purpose: novelty
+
+检查：
+
+- 核心差异在哪里：设计思路、实现方式、场景约束、资源模型，还是只是调参。
+- 与最相关已有工作相比，新挑战是否真实。
+- end-to-end 收益是否由核心差异带来。
+- 已有方法合理调整后是否可能达到类似效果。
+- 是否漏掉必须比较或必须引用的 competing method。
+
+## Purpose: simplicity
+
+检查：
+
+- 方法复杂度是否由 problem 本身驱动。
+- 是否有可删除组件、阶段、参数或特殊 case。
+- 是否存在“目标很小，机制很重”的不匹配。
+- 如果能简化，给出具体假设：去掉 X 后还应保留哪些收益。
+
+## Purpose: writing-kaashoek-style
+
+写作规则：
+
+- 先结论，再理由，再证据。
+- 句子短，一句一个意思。
+- 每段第一句就是 point。
+- 一段只讲一件事。
+- 数据和名词优先于形容词。
+- 早定义术语，不 use-before-define。
+- 删除 “we believe”, “it is important to note that”, “significantly” 这类软话，除非后面立刻给数字。
+
+若改写段落，输出 `before / after`；after 必须更短、更直接。
+
+## Purpose: typos-and-references
+
+检查：
+
+- 拼写、时态、单复数、标点。
+- 图表编号、section 编号、交叉引用。
+- 引用格式一致性。
+- 应引而未引的关键工作。
+- venue、年份、作者、系统名是否明显错误。