菜单
实现任何功能或修复 bug 时，写实现代码之前必须使用。铁律：没有先看到失败的测试，就没有生产代码。触发词：写代码、实现功能、修bug、TDD、写测试。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
多视角学术论文同行评审。模拟 7 名独立审稿人（EIC + 3 同行审稿人 + 魔鬼代言人 + 编辑综合），含动态角色配置。支持完整评审、再评审（验证修改）、快速评估、方法论聚焦、苏格拉底引导、校准模式。触发词：审稿、同行评审、评审论文、模拟评审、编辑评审、review paper、peer review、manuscript review、referee report。
12 Agent 学术论文写作管线。10 种模式（完整/计划/大纲/修改/修改教练/摘要/文献综述/格式转换/引文检查/披露声明）。6 种论文类型，5 种引文格式，双语摘要，LaTeX/DOCX/PDF 输出。风格校准 + 写作质量检查 + 反模式检测。触发词：写论文、学术论文、修改论文、论文大纲、写摘要、引文检查、转LaTeX、格式转换、write paper、academic paper、revise paper、paper writing。
完整学术研究管线编排器。协调 deep-research、academic-paper、academic-paper-reviewer 为 10 阶段无缝工作流：选题→调研→写作→完整性检查→评审→修改→再评审→再修改→最终检查→定稿。触发词：学术管线、研究到论文、完整论文流程、写一篇完整的论文、academic pipeline、research to paper、full paper workflow、end-to-end paper。
通用深度研究学术 Agent 团队。13 个 Agent 组成的学术研究管线，覆盖选题、文献检索、证据验证、综合分析到 APA 7.0 报告。7 种模式：完整研究、快速简报、论文评审、文献综述、事实核查、苏格拉底式引导研究、系统综述（含元分析）。触发词：研究、深度研究、文献综述、系统综述、PRISMA、证据综合、事实核查、引导我的研究、方向探索、research、deep research、literature review、systematic review、meta-analysis。
Academic Research Skills 学术研究技能集入口。覆盖从选题、文献调研、论文写作到同行评审的完整学术研究管线。触发词：写论文、深度研究、文献综述、同行评审、审稿、学术管线、research、paper、review。
创建精美的 HTML 演示文稿，支持从零创建、PPTX 转网页、或增强已有 HTML 演示。零依赖单文件，固定 16:9 比例，34 种设计模板。用户说要"做PPT""做演示文稿""创建slides""转换PPTX"时使用。
| name | test-driven-development |
| description | 实现任何功能或修复 bug 时，写实现代码之前必须使用。铁律：没有先看到失败的测试，就没有生产代码。触发词：写代码、实现功能、修bug、TDD、写测试。 |
| agent_created | true |
先写测试，看它失败，写最少代码让它通过。
如果你没看到测试失败，你就不知道它是否测试了正确的东西。
没有先看到失败的测试 = 没有生产代码
先写代码再写测试？删掉，重新来。
永远：
例外（需要人类伙伴确认）：
"就这一次跳过 TDD 吧"？停。那是合理化借口。
写一个最小测试展示应该发生什么。
好的测试：
def test_retries_failed_operations_three_times():
attempts = 0
def operation():
nonlocal attempts
attempts += 1
if attempts < 3:
raise Exception("fail")
return "success"
result = retry(operation)
assert result == "success"
assert attempts == 3
清晰命名，测试真实行为，只测一件事
差的测试：
def test_retry():
mock = Mock(side_effect=[Exception, Exception, "success"])
retry(mock)
assert mock.call_count == 3
模糊命名，测 mock 不是测代码
要求：
强制步骤，不可跳过。
pytest tests/path/test.py::test_name -v
确认：
测试直接通过？ 你在测已有行为，修正测试。
写最简单的代码让测试通过。不要：
强制步骤。
pytest tests/path/test.py::test_name -v
确认：
只在绿色之后：
保持测试绿色，不要添加行为。
下一个失败测试 → 下一个功能。
| 品质 | 好的 | 差的 |
|---|---|---|
| 最小 | 一件事。名字里有"和"？拆开。 | test_validates_email_and_domain() |
| 清晰 | 名字描述行为 | test1、test_works |
| 展示意图 | 展示期望的 API | 隐藏代码应该做什么 |
"我先写代码再补测试来验证"
事后写的测试立刻通过。立刻通过什么也证明不了：
| 借口 | 现实 |
|---|---|
| "太简单不用测" | 简单代码也会坏。写测试只花 30 秒。 |
| "我稍后补测试" | 测试立即通过证明不了任何事。 |
| "我已经手动测过了" | 临时的 ≠ 系统性的。没有记录，无法重跑。 |
| "删掉 X 小时工作太浪费" | 沉没成本谬误。保留未验证代码 = 技术债。 |
| "TDD 太死板，实际点" | TDD 就是实际的：提交前找到 bug（比事后调试快）。 |
| "保留做参考，先写测试" | 你会改编它。那就是测试后补。删除就是删除。 |
以下任何情况出现，意味着跳过 TDD：
以上全部意味着：删代码，用 TDD 重来。
完成前检查：