diff --git a/CLAUDE.md b/CLAUDE.md
index 79fbbf4..96017b7 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -66,10 +66,54 @@ references/<topic-slug>/            literature-search-verify 归档产出的稳
    的 `slugify()` 修了中文主题名被折叠成通用"references"名的问题;
    `scripts/tests/` 下补了 37 个 unittest 单测(全部mock,不发真实请求),
    覆盖上述所有改动。
-2. **新增"引用一致性核查" skill**:检查定稿里所有 `\cite{}` 的 key 是否都能在
-   对应主题的 `references/<slug>/references.bib` 里找到,以及有没有已归档
-   但从未被正文引用的"僵尸条目",在 literature-search-verify 和
-   paper-writing-grounded 之间补上这个校验环节。
+2. **新增"引用一致性核查" skill**(`citation-consistency-check`):检查定稿里
+   所有 `\cite{}` 的 key 是否都能在对应主题的 `references/<slug>/references.bib`
+   里找到,以及有没有已归档但从未被正文引用的"僵尸条目",在
+   literature-search-verify 和 paper-writing-grounded 之间补上这个校验环节。
+3. **新增"图表生成" skill**(`figure-from-data`,独立 skill,不并入
+   paper-writing-grounded):把全局 dataviz skill 的画图能力和本项目"数据不
+   能编"的红线结合起来——图上出现的每一个数字/误差棒/显著性标注都必须能
+   追溯到用户提供的真实数据,追溯不到就必须显式标记,不能为了图好看而插值/
+   编造。用户目前"才刚开始"做实验,这个和 reproducibility-checklist 一起
+   算当前阶段实际用得上的。
+4. **新增"实验可复现性自查" skill**(`reproducibility-checklist`):检查一个
+   实验结果和"跑出这个结果的环境/随机种子/超参数/代码版本"之间是否可追溯,
+   在博士研究早期建立这个记录习惯,比后期(投稿前)才补收益更大。具体检查
+   项和触发时机(每次跑完实验?还是准备写进论文前?)还需要进一步讨论确定。
+5. **新增"投稿格式合规检查" skill**(`submission-checklist`):投稿前检查页数
+   限制、双盲匿名化处理、模板合规、supplementary材料要求等——失败代价直接
+   (格式不合规可能直接被拒),但用户目前还没到投稿周期,优先级低于上面几项,
+   先记录设想,不着急做。
+6. **新增"审稿意见回复" skill**(`rebuttal-writing-grounded`):和
+   paper-writing-grounded 共享同一条红线——不能为了让回复显得更有说服力,
+   而承诺做不到的新实验或编造补充结果;但写作场景(逐条对应审稿人意见、
+   语气要求"礼貌但坚定")不同,应该做成姊妹 skill 而不是塞进
+   paper-writing-grounded 里。用户目前还没进入投稿/答辩周期,优先级最低,
+   先记录设想。
+7. **新增"实验设计常见陷阱清单" skill**(`experimental-design-checklist`,
+   优先级低、置信度低):不强制流程,只是一份"容易漏掉的检查项"提醒(有没有
+   设基线/消融、统计检验方法选得对不对、有没有偷偷用测试集调过参),因为
+   "实验设计得好不好"本质是统计学/领域判断力,skill 只能提醒别漏掉常见坑,
+   不能替用户判断设计是否合理——做的时候要非常克制,避免让用户误以为"清单
+   过了=设计没问题"。
+8. **新增"组会/答辩/会议报告大纲" skill**(`presentation-outline`,优先级低、
+   价值存疑):把已有的真实结果整理成报告大纲,同样要遵守"不编内容"的红线。
+   价值有限,因为这类大纲高度依赖听众和场合,通用流程能提供的帮助有限;暂
+   不确定要不要做,先记录设想。
+9. **新增"导师进展汇报" skill**(`advisor-progress-report`,优先级低、价值
+   存疑):从 git log / 实验记录整理成给导师的周报。风险是"总结不当会歪曲
+   实际进度"——如果做,必须严格限定为"只整理已确认的事实,不做主观进度
+   评估",且这类沟通策略本身因人而异,通用 skill 能提供的价值可能不大。
+10. **讨论过但决定不做**:
+    - "新颖性/查重式文献扫描"(检索这个想法是否已被做过)。结论是它和
+      literature-search-verify 的检索底层高度重合,而"够不够新颖"本质是
+      判断力问题,skill 顶多能帮忙把相关已有工作找全,这部分
+      literature-search-verify 已经能覆盖大半,边际价值不足以单独立项。
+    - "研究问题提出/创新点判断"。这是纯判断力/领域洞察力问题,不适合
+      productize——skill 最多能辅助"检索现有工作看有没有人做过"(即上一条
+      讨论过的新颖性扫描),但"这个问题值不值得做"必须是人的判断,做成
+      强流程 skill 反而有"流程走完=判断没问题"的误导风险。
+    - 以上两条如果以后发现实际需求很明确,可以重新评估这些决定。
 
 ## 新增 skill 时的约定