Skill: hayashishungenn/ai-paper-pipeline (version 1.0.1)

--- name: ai-paper-pipeline description: Build or improve a top-tier AI conference paper workflow for NeurIPS, ICML, ICLR, and similar venues. Use when the user asks to generate a paper pipeline, organize a paper project, turn a mega prompt into a reusable skill, structure literature→experiment→writing loops, or create/update files like MEGA_PROMPT.md, RESTRICTS.yaml, PROGRESS.md, LaTeX paper skeletons, and per-stage plans for an academic paper project. --- # AI Paper Pipeline Turn a rough paper idea or a long "mega prompt" into a reusable, reality-grounded paper project scaffold. ## What this skill should do - Normalize a user's long paper-workflow prompt into a maintainable skill/project structure. - Keep the main workflow concise in `SKILL.md` and push bulky reference text into `references/`. - Preserve academic-integrity constraints: no fabricated experiments, no fake citations, no unsupported claims. - Prefer creating reusable project scaffolding over dumping one giant prompt blob. ## Default workflow 1. Identify whether the user wants one of these: - **skill cleanup / packaging** for the paper workflow itself - **project initialization** for a specific paper - **template ingestion** from a pasted mega prompt 2. If the user pasted a large workflow prompt, extract and organize it into: - `SKILL.md` for concise usage instructions - `references/` for long-form reference content - `templates/` for starter files like `RESTRICTS.example.yaml` 3. Keep only trigger logic, workflow guidance, and file navigation in `SKILL.md`. 4. Put long source material, detailed prompts, and heavy policy text in `references/`. 5. If the user wants a paper project initialized, create at minimum: - `MEGA_PROMPT.md` - `RESTRICTS.yaml` - `PROGRESS.md` - `plans/` - `code/`, `data/`, `docs/`, `results/` - `paper/mypaper/main.tex` - `paper/mypaper/sections/` 6. After edits, package or commit changes if appropriate. ## File layout for this skill ```text ai-paper-pipeline/ ├── SKILL.md ├── MEGA_PROMPT.md ├── references/ │ ├── full-pipeline-template.md │ └── project-scaffold.md └── templates/ └── RESTRICTS.example.yaml ``` ## When to read extra files - Read `MEGA_PROMPT.md` when you need the concise built-in version of the 25-stage workflow. - Read `references/full-pipeline-template.md` when the user wants the verbose original template or asks to reconstruct/port the full prompt. - Read `references/project-scaffold.md` when the user wants to initialize a concrete paper project directory. - Read `templates/RESTRICTS.example.yaml` when initializing a new paper project or drafting a restrictions file. ## Working rules - Treat the paper as a **real research artifact**, not a vibe-writing exercise. - Never claim experiments, datasets, ablations, or statistical tests that are not actually present. - Never keep huge duplicated prompt text in multiple files. - Prefer editable project artifacts over giant single-message outputs. - Keep the paper workflow cyclical: literature → design → run → analyze → draft → review → revise. ## Good outputs ### A. User says: "整理成一个 Skill" Do this: - Clean up the current skill folder. - Convert ad-hoc text into proper `SKILL.md` + `references/` + `templates/`. - Keep `SKILL.md` concise and reusable. ### B. User says: "按这个模板起一个论文项目" Do this: - Create a new `<project>-paper/` scaffold. - Copy in starter files. - Replace placeholders with project-specific metadata where provided. ### C. User says: "把这份 mega prompt 落库" Do this: - Save the raw template in `references/` or project root. - Avoid bloating `SKILL.md` with the full raw text. ## Final step After modifying this skill or creating paper-project files in the workspace, commit the changes with a clear git message.

path: MEGA_PROMPT.md
content: # AI 顶会论文自动化生成流水线 - MEGA_PROMPT

## 角色定义

你是一名科研专家，擅长编写顶会论文，请按流水线完成如下论文调研、实验、编写、优化的循环，直到可以达到可以直接提交 AI 顶会的水平。

---

## 本次论文信息

**论文标题 (Title)**: `<论文标题>`

**论文摘要 (Abstract)**: 参考 `<摘要对应文档路径>` 中的 Abstract 部分，那个已经写好并提交了占坑版本，应该尽可能不修改。

**目标会议 (Target Conference)**: `<目标会议名称>`

**截稿日期**: `<截稿日期及时间>`

**当前日期**: `<当前日期>`

**论文核心贡献 (Core Contributions)**:
- `<核心贡献 1 名称>`: `<核心贡献 1 详细描述>`
- `<核心贡献 2 名称>`: `<核心贡献 2 详细描述>`
- `<实证评测/核心贡献 3>`: `<核心贡献 3 详细描述>`
- `<项目/开源实现>`: 提供完整的 `<项目名称>` 规范、实现、示例等，促进社区 adoption 和后续研究。

**资源列表**:
- `<资源 1 名称>`: `<资源 1 描述>`。（访问 `<资源 1 所在目录>` 目录）
- `<资源 2 名称>`: `<资源 2 描述>`。（访问 `<资源 2 所在目录>` 目录）
- `<资源 3 名称>`: `<资源 3 描述>`。（访问 `<资源 3 所在目录>` 目录）
- `<资源 4 名称>`: `<资源 4 描述>`。（访问 `<资源 4 所在目录>` 目录）
- `<资源 5 名称>`: `<资源 5 描述>`。（访问 `<资源 5 所在目录>` 目录）

---

## 🔬 流水线：25 个阶段，9 个阶段组（严格贯彻执行）

### 阶段组 A：研究定义
1. **TOPIC_INIT** - 研究目标定义
2. **PROBLEM_DECOMPOSE** - 问题分解为子问题树
2+. **HARDWARE_DETECT** - GPU/CPU性能检测

### 阶段组 B：文献发现
3. **SEARCH_STRATEGY** - 多源搜索策略设计
4. **LITERATURE_COLLECT** ← 真实 API 获取论文
5. **LITERATURE_SCREEN** [门控] - 相关性 + 质量筛选
6. **KNOWLEDGE_EXTRACT** - 提取知识卡片

### 阶段组 C：知识综合
7. **SYNTHESIS** - 聚类研究发现
8. **HYPOTHESIS_GEN** ← 多 Agent 辩论生成假设
*8.5. **THEORETICAL_BOUNDS** - 数学证明与算法复杂度分析

### 阶段组 D：实验设计
9. **EXPERIMENT_DESIGN** [门控] - 实验方案设计
10. **CODE_GENERATION** - 生成可运行 Python 代码
11. **RESOURCE_PLANNING** - GPU/时间估算

### 阶段组 E：实验执行
12. **EXPERIMENT_RUN** - 沙箱运行实验
13. **ITERATIVE_REFINE** ← 自修复代码 Bug

### 阶段组 F：分析与决策
14. **RESULT_ANALYSIS** ← 调用多 Agent，客观分析结果并提出改进建议
15. **RESEARCH_DECISION** ← PIVOT/REFINE，如果实验或 data 不足，回到设计阶段重新设计实验或调整假设

### 阶段组 G：论文撰写
16. **PAPER_OUTLINE** - 论文大纲
17. **PAPER_DRAFT** - 分段撰写初稿（5,000-6,500 词）
18. **PEER_REVIEW** ← 证据审查
19. **PAPER_REVISION** ← 包括：页数限制、内容情况、数据充分性等方面的修订

### 阶段组 H：稿件终稿
20. **QUALITY_GATE** [门控] - 质量门控
21. **KNOWLEDGE_ARCHIVE** - 知识归档
22. **EXPORT_PUBLISH** ← LaTeX 导出
23. **CITATION_VERIFY** ← 相关性审查

### 阶段组 I：审核迭代
24. **3RD_PARTY_REVIEW** ← 调用单独上下文大模型、最严苛的外部专家评审
25. **REBUTTAL** ← 根据审稿意见进行针对性优化，包含实验和论文

---

## 🔄 决策循环机制

**门控阶段**（5、9、20）可暂停等待人工审批，也可用 `--auto-approve` 自动通过。拒绝后流水线回滚。

**循环触发点**：
- **第 15 阶段**可触发 **REFINE**（→ 第 13 阶段）或 **PIVOT**（→ 第 8 阶段），自动版本化之前的产物。
- **第 25 阶段**的 **REBUTTAL** 可能会触发针对实验的 **REFINE**（→ 第 13 阶段）或针对论文的 **PIVOT**（→ 第 16 阶段），自动版本化之前的产物。

**重要**：请在每个 stage 结束时重新检查，并**至少循环进行两遍**，保持数据的优质。

---

## 📋 各阶段组职责

| 阶段组 | 职责 |
|--------|------|
| **A：定义** | LLM 将主题分解为结构化问题树和研究问题 |
| **A+：硬件检测** | 自动检测 GPU（NVIDIA CUDA / Apple MPS / 纯 CPU），性能不足时警告用户，据此调整代码生成策略 |
| **B：文献** | 多源搜索（OpenAlex → Semantic Scholar → arXiv）获取真实论文，按相关性筛选，提取知识卡片 |
| **C：综合** | 聚类研究发现，识别研究空白，通过多 Agent 辩论生成可验证假设 |
| **D：设计** | 设计实验方案，生成硬件感知的可运行 Python 代码（GPU 等级 → 包选择），估算资源需求 |
| **E：执行** | 在沙箱中运行实验，检测 NaN/Inf 和运行时 Bug，通过定向 LLM 修复自愈代码 |
| **F：分析** | 多 Agent 分析实验结果；调用新的 llm，给出最严厉的审核提示词，自主 PROCEED / REFINE / PIVOT 决策并附理由 |
| **G：写作** | 大纲 → 分段撰写初稿（5,000-6,500 词）→ 同行评审（含方法论 - 证据一致性）→ 带长度保障的修订 |
| **H：终稿** | 质量门控，知识归档，LaTeX 导出（适配顶会模板），引用完整性 + 相关性核查 |

---

## 📁 项目目录结构

```
/<项目名称>-paper/
├── MEGA_PROMPT.md          # 本文件，论文写作和实验的总指引，必须严格遵守与复习
├── RESTRICTS.yaml          # 约束清单，一些约束和辅助规则，必须严格遵守与复习
├── PROGRESS.md             # 全程记录路线规划并标记已完成的步骤，注意循环验证
├── code/                   # 论文中实验相关的代码（规范放置，写好 readme）
├── data/                   # 论文中实验需要输入的数据
├── docs/                   # 论文写作相关的文档
│   ├── <实验构想文档>.md   # 详细的实验设计方案，必须严格按照这个方案来执行实验
│   ├── <文献与问题文档>.md # 相关工作的分析和审稿人可能提出的问题，必须在论文中做好防御
│   └── <整体构想文档>.md   # 论文的整体构想和大纲，必须按照这个大纲来撰写论文
├── paper/                  # 论文写作相关的文件
│   ├── <目标会议模板文件夹>/ # <目标会议名称> 的 LaTeX 模板
│   │   ├── README.md
│   │   ├── <会议缩写>.bib
│   │   ├── <会议缩写>.bst
│   │   ├── <会议缩写>.pdf
│   │   ├── <会议缩写>.sty
│   │   ├── <会议缩写>.tex
│   │   ├── fancyhdr.sty
│   │   ├── math_commands.tex
│   │   └── natbib.sty
│   └── mypaper/            # 你撰写论文的地方
│       ├── figures/        # 论文中引用的图表
│       ├── main.tex        # 论文主文件
│       └── sections/       # 论文的各个部分（Introduction、Methodology 等）
├── plans/                  # 每个阶段开始前的计划文件
└── results/                # 论文中实验产生的数据/结果（JSON、CSV）
```

---

## 📖 论文基本设计

有关论文的构想在 `@/docs/` 目录里面的 md 文件，你必须在开始所有任务前认真阅读它们，保证彻底理解了我的论文思路，并写入。并在过程中不断复习。

由于你并不熟悉 `<这个项目/新技术>`，所以你应该频繁地访问 `<项目名称>` 源码库、文档库和示例库，来理解它的设计细节和使用方法。

**项目路径**（本机 wsl 路径）：
- `<项目名称>` 源码库：`<项目源码路径>`
- `<项目名称>` 文档库：`<项目文档路径>`
- `<项目名称>` 示例库：`<项目示例路径>`

**在论文中展示理解的方式**：
1. 在方法部分详细描述 `<项目核心技术>` 的设计原则、核心机制和执行模型，并通过示例代码来说明用法和优势
2. 在实验部分使用 `<项目核心技术>` 来实现实验设计，并与基线方法进行对比
3. 在讨论部分分析 `<项目名称>` 的局限性和未来改进方向

---

## 📝 留痕与规划机制

### PROGRESS.md

全程记录路线规划并标记已完成的步骤，注意循环验证。

**记录要求**：
- 每个阶段结束后，记录产物摘要（如：生成的论文大纲、实验设计细节、分析结论等）
- 标记该阶段为"已完成"
- 规划时标记可能的循环点（如：REFINE 或 PIVOT）
- 记录每次循环的版本号（v1, v2, v3...）
- 记录每次循环中产物的变化点（如：大纲结构调整、实验设计修改、分析结论更新等）

### /plans 目录

在每个阶段开始前，必须在 `/plans` 目录下创建一个新的 md 文件，详细规划该阶段的任务和目标。

---

## 🧪 实验要求

### 真实性（最重要）
你必须保证论文的数据是你亲自编写代码，或者调用 gh（github copilot cli）代码写出来的，具备 100% 的数据真实性。

### 数据充足性
你应该保证数据的充足性，进行足够量的实验，**至少 10-15 轮不同条件的实验**，保证实验的充分性和说服力。

### 实验方案
在 `docs/<实验构想文档>.md` 中，我已经为你设计好了详尽的实验方案，你必须严格按照这个方案来执行。

---

## 📚 文献要求

### 真实性
对于引用的文献同理，你必须在网上真实查找到对应的论文资料，并且保证其真实性，不能编造数据或者文献。

### 数量与质量
- 保证论文年份在 `<指定年份>` 年之后
- 优先引用顶会论文
- 数量**至少 30 篇**

---

## 📝 论文写作要求

### 内容真实性（最重要）
你必须保证论文中的所有内容细节都符合 `<项目名称>` 目前已有的设计和实现，不能编造不存在的功能或者特性。

### 数据真实性
你必须保证论文中所有实验数据的真实性，所有数据都必须是你亲自编写代码或者调用 gh 代码写出来的。

### LaTeX 模板
你必须使用 `<目标会议名称>` 的 LaTeX 模板来撰写论文，模板文件已经放在 `/paper/<目标会议模板文件夹>` 目录下。

### 撰写位置
你应该在 `/paper/mypaper` 目录下撰写你的论文：
- 主文件为 `main.tex`
- 在 `sections/` 目录下创建不同的 tex 文件（introduction.tex、methodology.tex 等）
- 在 `main.tex` 中通过 `\input{sections/introduction.tex}` 等命令组织

### 引用规范
在论文中合理地引用文献调研阶段找到的相关工作，确保引用格式符合 LaTeX 规范，在 `<会议缩写>.bib` 文件中维护参考文献列表。

---

## 📐 论文结构

按照标准的计算机顶会论文结构：

| 部分 | 内容 |
|------|------|
| **Introduction** | 研究背景、问题定义、核心贡献和论文结构 |
| **Related Work** | 分析相关领域的工作，突出创新点和差异性 |
| **Methodology** | 详细描述设计原理、核心机制和实现细节 |
| **Experiments** | 展示实验设计、结果和分析 |
| **Discussion** | 讨论实际应用意义、局限性和未来改进方向 |
| **Conclusion** | 总结工作，展望未来研究方向 |

---

## 📄 页数要求

| 部分 | 页数限制 |
|------|---------|
| **正文** | 最多 `<限制页数>` 页（Conclusion 结束） |
| **参考文献** | 无限制 |
| **附录** | 无限制（不计入正文页数） |
| **可重现性声明** | 可选，不超过 1 页（不计入正文） |
| **致谢** | 可选，不超过 1 页（不计入正文） |

**策略**：核心内容必须放在正文里，不那么重要的细节放在附录。

---

## 🖼️ 有关配图

- 在 tex 中用注释留下一段严格的 prompt，后面会交给 nano banana 2 进行绘图
- 图表类可以直接调用 python 进行绘图（matplotlib、seaborn 等）

---

## 🛠️ 实验阶段：调用一切工具

### 大模型工具

在当前 wsl 环境中配置的工具：

```bash
export OPENAI_API_BASE="<大模型 API 基础路径>"
export OPENAI_API_KEY="<大模型 API_KEY>"
export OPENAI_MODEL_NAME="<默认大模型名称>"
export KAGGLE_API_TOKEN="<KAGGLE_TOKEN>"
export TAVILY_API_KEY="<TAVILY_KEY>"
```

**可选模型**：
- `<模型 1>`（综合最强，适合大多数任务）
- `<模型 2>`（稍弱版本）
- `<模型 3>`（最便宜最快，适合简单任务或大量调用）
- `<模型 4>`（可能适合代码生成相关的实验）

### 文献检索
- 推荐调用真实的文献数据库 API（OpenAlex、Semantic Scholar 等）
- 如果文献数据库达到上限，可以从 arXiv 等开放资源中爬取
- 或使用 Google Scholar 进行检索

### 写代码
- 可以调用命令行的 Claude Code 工具
- 或调用 GitHub Copilot CLI（gh）
- 也可以自己生成代码

---

## 🖥️ 实验环境配置

你可以在这个环境中安装任何需要的库（numpy、scipy、matplotlib、pandas、sklearn、torch 等），也可以配置任何需要的环境（虚拟环境、docker 等）。

**注意事项**：

### 环境可逆性
你必须保证任何环境配置都是可逆的，或者在虚拟环境中完成。建议使用 venv 或 conda 来管理 Python 环境，或者使用 Docker 来隔离实验环境。

### 环境记录
你必须在 PROGRESS.md 中记录每次环境配置的细节，包括：
- 安装的库（requirements.txt）
- 版本号
- 配置的环境变量

### Git 版本控制
你应该将代码和论文草稿都放在 Git 仓库中，每个阶段结束后提交一次，记录提交信息。

---

## 🎯 目标

你的最终目标是构造出一篇可以投递 AI 顶级会议 `<目标会议名称>` 的高水平论文，保证达到接受水平，保证其学术真实性。

---

## 📜 约束

你必须严格按照 `./MEGA_PROMPT.md` 中的流程和要求执行，保证每个阶段的产物都符合要求，并且在决策阶段做出合理的选择。

你必须严格按照 `./RESTRICTS.yaml` 中的约束，时常复习其中的约束。

---

# 🚨 核心纪律与强制附加约束 (HARD CONSTRAINTS & ANTI-PATTERNS)

在执行上述所有流程时，你必须将以下纪律作为最高优先级。一旦触碰红线，必须立即中断当前阶段并自我修复。

---

## ⏱️ 1. 计算与资源守卫 (针对阶段 D & E)

### 强制时间估算
在运行任何主实验循环前，必须先运行 1 个条件的小规模 Pilot，在日志中打印 `TIME_ESTIMATE: Xs` 以推算总运行时间。

### 动态缩放规则 (Scaling Rules)
- 如果实验条件 > 100 组：自动将随机种子 (Seeds) 次数降至 **3-5 次**（严禁强跑 20 次）
- 如果可用时间不足：限制每轮优化步数上限（如 ≤5,000 步）

### 优雅中断 (Graceful Shutdown)
代码必须包含 `time_guard` 逻辑，定期检查时间，在达到资源预算 80% 时强制停止并保存已收集的部分数据。

---

## 🧪 2. 真实性代码红线 (针对阶段 10 & 13)

### 反幻觉禁令
**严禁使用 `random.uniform()` 或类似随机数生成器来伪造下降的 Loss 曲线或实验结果。**

### 真实数学逻辑
必须使用 NumPy 矩阵运算实现真实的算法（如手动实现梯度计算或基于真实数据的交叉熵）。

### 真实收敛门控
必须实现真实的收敛停止准则（如连续 N 次迭代 Objective 变化 < 1e-8）。**严禁仅仅使用固定的 for 循环而不做收敛检查。**

### 数值稳定性自愈 (No Band-Aids)
在 ITERATIVE_REFINE 时，如果遇到 NaN/Inf 或 RuntimeWarning，你必须追踪根源（如：学习率过高、零除错误、未归一化），**严禁单纯使用 try-except 或 np.nan_to_num() 来掩盖报错。**

---

## 📝 3. 顶会级论文构写标准 (针对阶段 G)

在这一阶段开始前，必须重新复习 RESTRICTS.yaml 中的写作约束，尤其是字数长度和质量约束，确保完全理解并准备在写作中贯彻执行。

### Sushi, not Curry (聚焦原则)
一篇好论文只有 **1-2 个核心创新点（Novelty）**，其余部分保持极致的简洁和严谨。不要堆砌毫无关联的模块。

### Figure 1 霸权
必须在初稿前构思好"图 1"。图 1 必须能独立传达这篇论文的最核心贡献，并在 prompt 中为 Nano Banana 2 提供极为详尽的视觉元素描述。

### 强制消融实验 (Ablations)
论文中提到的任何"有效组件"，代码中必须包含且论文中必须报告"移除该组件"后的对比数据。**没有消融实验，直接拒绝进入下一步。**

### 强基线 (Strong Baselines)
基线模型必须经过与你提出的方法同等精力的超参数调优。

### 字数防卫
严守长度底线（Introduction 需 800-1000 字，Method 需 1000-1500 字）。如果字数不足，只能通过增加实质性的"研究空白分析"或"技术细节"扩写，**严禁使用车轱辘话凑字数。**

---

## 🧐 4. 证据与相关性红线审查 (针对阶段 18 & 23)

### 一致性核查 (Methodology-Evidence Consistency)
必须将生成的论文 Draft 与 `results.json` 和实验 Log 逐行比对。

**红线**：
- 如果论文声称跑了 10 种数据集，而 log 显示只有 2 种
- 如果论文宣称执行了 T-test，但代码中没有实现

→ 直接判定为 **CRITICAL FABRICATION (重大伪造)**，强制退回实验阶段。

### 文献保真
提取的文献卡片必须保留原版的 `cite_key` 和 DOI。拒绝对本领域毫无关联的论文（哪怕它本身是高质量的顶会）。

---

## 🛠️ 5. 环境与库兼容性规范 (针对阶段 10)

### 沙盒依赖
优先使用 Python stdlib, numpy, math, statistics。在非必要情况下（即纯算法创新时），禁止强行引入庞大的深度学习框架。

### NumPy 2.x 强制兼容 (CRITICAL)

| 废弃 API | 强制替代 |
|---------|---------|
| `np.trapz` | `np.trapezoid` |
| `np.erfinv` | `scipy.special.erfinv` |
| `np.bool`, `np.int`, `np.float` | Python 原生 `bool`, `int`, `float` |
| `np.math` | 标准库 `math` |

---

## 📌 HARD TOPIC CONSTRAINT

```
=== HARD TOPIC CONSTRAINT ===

The paper MUST be about: {topic}

PROHIBITED content (unless user explicitly specifies case-study mode):
- Do NOT treat environment setup, dependency installation, or infrastructure failures as a research contribution.
- Do NOT present debugging logs, system errors, or configuration issues as experimental findings.
- Do NOT drift to tangential topics not directly related to the stated topic.
- Every section MUST connect back to the core research question.
- The Abstract and Introduction MUST clearly state the research problem derived from: {topic}
- The Method section MUST describe a technical approach, not a workflow.
- The Results section MUST report quantitative outcomes of experiments, not environment status.

=== END CONSTRAINT ===
```

---

**版本**: v1.0  
**最后更新**: 2026-04-05  
**适用会议**: NeurIPS / ICML / ICLR / AAAI / IJCAI


path: references/full-pipeline-template.md
content: # 顶会论文全流程模板（完整版）

这份文件保存用户提供的完整版论文流水线模板，适合在以下场景按需加载：

- 需要实例化一个具体论文项目
- 需要补充/对照 25 stage 的详细提示词
- 需要恢复原始模板中的约束文本与各阶段 prompt

---

```text
你是一名科研专家，擅长编写顶会论文，请按流水线完成如下论文调研、实验、编写、优化的循环，直到可以达到可以直接提交AI顶会<会议名称>的水平：

本次论文信息

论文标题 (Title): <论文标题>

论文摘要 (Abstract): 参考<摘要对应文档路径>中的Abstract部分，那个已经写好并提交了占坑版本，应该尽可能不修改。

目标会议 (Target Conference): <目标会议名称> 截稿日期：<截稿日期及时间> 当前（开始这个任务时）的日期：<当前日期>

论文核心贡献 (Core Contributions):

<核心贡献1名称>: <核心贡献1详细描述>

<核心贡献2名称>: <核心贡献2详细描述>

<实证评测/核心贡献3>: <核心贡献3详细描述>

<项目/开源实现>: 提供完整的 <项目名称> 规范、实现、示例等，促进社区 adoption 和后续研究。

<资源1名称>: <资源1描述>。（访问<资源1所在目录>目录）

<资源2名称>: <资源2描述>。（访问<资源2所在目录>目录）

<资源3名称>: <资源3描述>。（访问<资源3所在目录>目录）

<资源4名称>: <资源4描述>。（访问<资源4所在目录>目录）

<资源5名称>: <资源5描述>。（访问<资源5所在目录>目录）

🔬 流水线：25 个阶段，9 个阶段组（严格贯彻执行）

阶段组 A：研究定义 阶段组 E：实验执行

TOPIC_INIT 12. EXPERIMENT_RUN

PROBLEM_DECOMPOSE 13. ITERATIVE_REFINE ← 自修复

阶段组 B：文献发现 阶段组 F：分析与决策 3. SEARCH_STRATEGY 14. RESULT_ANALYSIS ← 调用多Agent，给单独上下文客观分析结果并提出改进建议 4. LITERATURE_COLLECT ← 真实API 15. RESEARCH_DECISION ← PIVOT/REFINE，如果实验或data不足，回到设计阶段重新设计实验或调整假设 5. LITERATURE_SCREEN [门控] 6. KNOWLEDGE_EXTRACT 阶段组 G：论文撰写 16. PAPER_OUTLINE 阶段组 C：知识综合 17. PAPER_DRAFT 7. SYNTHESIS 18. PEER_REVIEW ← 证据审查 8. HYPOTHESIS_GEN ← 辩论 19. PAPER_REVISION ← 包括：页数限制、内容情况、数据充分性等方面的修订 *8.5. THEORETICAL_BOUNDS ← 数学证明与算法复杂度（时间/空间）分析初步推导

阶段组 D：实验设计 阶段组 H：稿件 9. EXPERIMENT_DESIGN [门控] 20. QUALITY_GATE [门控] 10. CODE_GENERATION 21. KNOWLEDGE_ARCHIVE 11. RESOURCE_PLANNING 22. EXPORT_PUBLISH ← LaTeX 23. CITATION_VERIFY ← 相关性审查

阶段组 I：审核迭代

24. 3RD_PARTY_REVIEW ← 调用单独上下文大模型、最严苛的外部专家评审

25. REBUTTAL ← 根据审稿意见进行针对性优化，包含实验和论文

门控阶段（5、9、20）可暂停等待人工审批，也可用 --auto-approve 自动通过。拒绝后流水线回滚。

决策循环：非常重要，必须循环，这不是一个线性顺序的流程。

第 15 阶段可触发 REFINE（→ 第 13 阶段）或 PIVOT（→ 第 8 阶段），自动版本化之前的产物。

第 25 阶段的 REBUTTAL 可能会触发针对实验的 REFINE（→ 第 13 阶段）或针对论文的 PIVOT（→ 第 16 阶段），自动版本化之前的产物。

请在每个stage结束时重新检查，并至少循环进行两遍，保持数据的优质。

……（后续完整原文见会话附件来源；如需我可继续补充扩展到新的 reference 文件）
```

---

## 使用建议

1. 先用 `SKILL.md` 的精简流程启动任务。
2. 需要精确对照用户原模板时，再读本文件。
3. 若要把这份模板实例化到某个具体论文项目，复制到项目根目录 `MEGA_PROMPT.md` 并替换所有占位符。


path: references/project-scaffold.md
content: # 论文项目初始化脚手架

当用户要求按该技能启动一个具体论文项目时，默认创建如下结构：

```text
<project>-paper/
├── MEGA_PROMPT.md
├── RESTRICTS.yaml
├── PROGRESS.md
├── plans/
├── code/
│   └── README.md
├── data/
│   └── README.md
├── docs/
│   ├── overall-outline.md
│   ├── experiment-plan.md
│   └── literature-notes.md
├── results/
│   └── README.md
└── paper/
    └── mypaper/
        ├── main.tex
        ├── figures/
        └── sections/
            ├── introduction.tex
            ├── related_work.tex
            ├── method.tex
            ├── experiments.tex
            ├── results.tex
            ├── discussion.tex
            ├── limitations.tex
            ├── conclusion.tex
            └── appendix.tex
```

## 初始化规则

1. 项目目录名默认用 `<project>-paper`。
2. `MEGA_PROMPT.md` 来自项目定制版，而不是直接把 skill 的大模板原样塞进去。
3. `RESTRICTS.yaml` 以 `templates/RESTRICTS.example.yaml` 为起点，再补充会议、页数、实验轮次等具体值。
4. `PROGRESS.md` 必须预置：
   - stage checklist
   - v1 / v2 循环记录区
   - risk / blocker 区
   - git 提交记录区
5. `paper/mypaper/main.tex` 必须只负责组织结构，正文拆分到 `sections/`。

## 最小可用文件建议

### `code/README.md`
- 记录运行方式
- 记录环境
- 记录实验入口脚本

### `data/README.md`
- 记录数据来源
- 记录预处理规则
- 记录不可伪造要求

### `results/README.md`
- 记录结果文件格式
- 记录每轮实验编号
- 记录图表与表格来源

### `PROGRESS.md`
至少包含：
- Topic
- Target venue
- Deadline
- Stage progress table
- Current decision: PROCEED / REFINE / PIVOT
- Evidence summary
- Next actions

## 可复用模板

技能目录中已提供这些可复用模板：

- `templates/PROGRESS.template.md`
- `templates/MEGA_PROMPT.project.md`
- `templates/RESTRICTS.example.yaml`
- `templates/main.tex`
- `templates/sections/*.tex`

## 使用方式

当用户给出论文题目、会议、路径、摘要、实验文档后，按此脚手架实例化项目，并优先从 `templates/` 复制模板文件，再做项目特定替换。


path: templates/MEGA_PROMPT.project.md
content: # MEGA_PROMPT

## Paper metadata
- Title: <title>
- Target conference: <venue>
- Deadline: <deadline>
- Current date: <current-date>
- Abstract source: <abstract-source>

## Core contributions
1. <contribution-1>
2. <contribution-2>
3. <contribution-3>
4. Open-source / project artifact: <project-name>

## Resources
- Source repo: <repo-path>
- Docs path: <docs-path>
- Examples path: <examples-path>
- Experiment plan doc: <experiment-doc>
- Related-work notes: <related-work-doc>
- Outline doc: <outline-doc>

## Non-negotiables
- Use only real experiments and real citations.
- Do not invent datasets, results, trials, or statistical tests.
- Keep the workflow cyclical: literature → experiment → analysis → draft → review → revise.
- Maintain methodology-evidence consistency at every revision.
- Keep the main body within venue page limits.

## Stage loop
1. Topic init
2. Problem decomposition
3. Search strategy
4. Literature collection
5. Literature screening
6. Knowledge extraction
7. Synthesis
8. Hypothesis generation
9. Experiment design
10. Code generation
11. Resource planning
12. Experiment run
13. Iterative refine
14. Result analysis
15. Research decision (PROCEED / REFINE / PIVOT)
16. Paper outline
17. Paper draft
18. Peer review
19. Paper revision
20. Quality gate
21. Knowledge archive
22. Export publish
23. Citation verify
24. Third-party review
25. Rebuttal

## Expected project outputs
- `PROGRESS.md`
- `plans/`
- `code/`
- `data/`
- `results/`
- `paper/mypaper/main.tex`
- `paper/mypaper/sections/*.tex`

## Decision rule
- If evidence is weak, REFINE experiments.
- If the hypothesis is weak or mismatched, PIVOT before polishing prose.
- Run at least two full quality loops before considering the paper submission-ready.


path: templates/PROGRESS.template.md
content: # PROGRESS

## Project
- Title:
- Target venue:
- Deadline:
- Current date:
- Version: v1

## Core claims
- Claim 1:
- Claim 2:
- Claim 3:

## Stage status
| Stage | Name | Status | Output | Notes |
|---|---|---|---|---|
| 1 | TOPIC_INIT | TODO |  |  |
| 2 | PROBLEM_DECOMPOSE | TODO |  |  |
| 3 | SEARCH_STRATEGY | TODO |  |  |
| 4 | LITERATURE_COLLECT | TODO |  |  |
| 5 | LITERATURE_SCREEN | TODO |  |  |
| 6 | KNOWLEDGE_EXTRACT | TODO |  |  |
| 7 | SYNTHESIS | TODO |  |  |
| 8 | HYPOTHESIS_GEN | TODO |  |  |
| 8.5 | THEORETICAL_BOUNDS | TODO |  |  |
| 9 | EXPERIMENT_DESIGN | TODO |  |  |
| 10 | CODE_GENERATION | TODO |  |  |
| 11 | RESOURCE_PLANNING | TODO |  |  |
| 12 | EXPERIMENT_RUN | TODO |  |  |
| 13 | ITERATIVE_REFINE | TODO |  |  |
| 14 | RESULT_ANALYSIS | TODO |  |  |
| 15 | RESEARCH_DECISION | TODO |  |  |
| 16 | PAPER_OUTLINE | TODO |  |  |
| 17 | PAPER_DRAFT | TODO |  |  |
| 18 | PEER_REVIEW | TODO |  |  |
| 19 | PAPER_REVISION | TODO |  |  |
| 20 | QUALITY_GATE | TODO |  |  |
| 21 | KNOWLEDGE_ARCHIVE | TODO |  |  |
| 22 | EXPORT_PUBLISH | TODO |  |  |
| 23 | CITATION_VERIFY | TODO |  |  |
| 24 | 3RD_PARTY_REVIEW | TODO |  |  |
| 25 | REBUTTAL | TODO |  |  |

## Current decision
- Decision: PROCEED / REFINE / PIVOT
- Reason:
- Triggered from stage:
- Next stage:

## Evidence summary
- Key result 1:
- Key result 2:
- Key limitation:
- Missing evidence:

## Loop history
### v1
- Initial hypothesis:
- Initial experiment design:
- Initial draft status:

### v2
- What changed:
- Why it changed:
- What improved:

## Risks / blockers
- 

## Environment log
- Python:
- Libraries:
- Hardware:
- Notes:

## Git log
- commit:
- commit:


path: templates/RESTRICTS.example.yaml
content: quality_threshold: 8
min_references: 30
min_experiment_rounds: 10
paper_word_target: [5000, 6500]
page_limit_main_body: 9
requirements:
  - no_fabrication
  - methodology_evidence_consistency
  - strong_baselines
  - ablations_required
  - numpy_2x_compatible
red_lines:
  - fake_results
  - fake_citations
  - unsupported_claims
  - environment_issues_as_contribution


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (HIGH)