/aris-paper-plan
Generate a structured paper outline from review conclusions and experiment results. Use when user says \"写大纲\", \"paper outline\", \"plan the paper\", \"论文规划\", or wants to create a paper plan before writing.
$ npx -y skills add OpenLAIR/dr-claw --skill aris-paper-plan --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/aris-paper-plan
Context preview
The summary Claude sees to decide when to auto-load this skill.
Generate a structured paper outline from review conclusions and experiment results. Use when user says \"写大纲\", \"paper outline\", \"plan the paper\", \"论文规划\", or wants to create a paper plan before writing.
SKILL.md
aris-paper-plan.SKILL.mdname: aris-paper-plan
description: "Generate a structured paper outline from review conclusions and experiment results. Use when user says \"写大纲\", \"paper outline\", \"plan the paper\", \"论文规划\", or wants to create a paper plan before writing."
argument-hint: "[topic-or-narrative-doc]"
allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, Agent, WebSearch, WebFetch, mcp__codex__codex, mcp__codex__codex-reply
license: MIT
metadata:
author: wanshuiyin/ARIS
version: "1.0.0"
Paper Plan: From Review Conclusions to Paper Outline
Generate a structured, section-by-section paper outline from: **$ARGUMENTS**
Constants
- **REVIEWER_MODEL = `gpt-5.4`** — Model used via Codex MCP for outline review. Must be an OpenAI model.
- **TARGET_VENUE = `ICLR`** — Default venue. User can override (e.g., `/aris-paper-plan "topic" — venue: NeurIPS`). Supported: `ICLR`, `NeurIPS`, `ICML`, `CVPR`, `ACL`, `AAAI`, `ACM`, `IEEE_JOURNAL` (IEEE Transactions / Letters), `IEEE_CONF` (IEEE conferences).
- **MAX_PAGES** — Page limit. For ML conferences: main body to Conclusion end (excluding references, appendix). ICLR=9, NeurIPS=9, ICML=8. **For IEEE venues: references ARE included in page count.** IEEE journal Transactions ≈ 12-14 pages total, Letters ≈ 4-5 pages total; IEEE conference ≈ 5-8 pages total (including references).
Inputs
The skill expects one or more of these in the project directory:
1. **NARRATIVE_REPORT.md** or **STORY.md** — research narrative with claims and evidence 2. **GPT54_AUTO_REVIEW.md** — auto-review loop conclusions 3. **Experiment results** — JSON files in `figures/`, screen logs, tables 4. **IDEA_REPORT.md** — from idea-discovery pipeline (if applicable) 5. **Compact files** (if available): `IDEA_CANDIDATES.md`, `findings.md`, `EXPERIMENT_LOG.md` — preferred over full files when present, saves context window
If none exist, ask the user to describe the paper's contribution in 3-5 sentences.
Orchestra-Guided Writing Overlay
Keep the existing `insleep` workflow and outputs, but use the shared references below to improve the quality of the story and outline.
- Read `../shared-references/writing-principles.md` when framing the one-sentence contribution, Abstract, Introduction, Related Work, or hero figure.
- Read `../shared-references/venue-checklists.md` before freezing the outline for a specific venue.
- Only load these references when needed; do not paste their full contents into the working draft.
Workflow
Step 1: Extract Claims and Evidence
**First check for `CLAIMS_FROM_RESULTS.md`** — if it exists (generated by `/aris-result-to-claim` at the end of Workflow 2), use it as the starting point for claims. This file contains validated claims already mapped to experiment evidence. Merge with any additional claims from the narrative documents below.
If `CLAIMS_FROM_RESULTS.md` does not exist, extract claims from scratch:
Read all available narrative documents and extract:
1. **Core claims** (3-5 main contributions) 2. **One-sentence contribution** (the single sentence that best states what the paper contributes) 3. **Evidence** for each claim (which experiments, which metrics, which figures) 4. **Known weaknesses** (from reviewer feedback) 5. **Suggested framing** (from review conclusions)
Build a **Claims-Evidence Matrix**:
| Claim | Evidence | Status | Section |
|-------|----------|--------|---------|
| [claim 1] | [exp A, metric B] | Supported | §3.2 |
| [claim 2] | [exp C] | Partially supported | §4.1 |
Step 2: Determine Paper Type and Structure
Based on TARGET_VENUE and paper content, classify and select structure.
Before committing to a structure, apply the narrative principle from `../shared-references/writing-principles.md`:
- The paper should tell one coherent technical story.
- By the end of the Introduction, the outline should make the **What**, **Why**, and **So What** explicit.
- Front-load the most important material: title, abstract, introduction, and hero figure. Reviewers often form a judgment before reading the full method.
**IMPORTANT**: The section count is FLEXIBLE (5-8 sections). Choose what fits the content best. The templates below are starting points, not rigid constraints.
**Empirical/Diagnostic paper:**
1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Method / Setup (1.5 pages)
4. Experiments (3 pages)
5. Analysis / Discussion (1 page)
6. Conclusion (0.5 pages)
**Theory + Experiments paper:**
1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Preliminaries & Modeling (1.5 pages)
4. Experiments (1.5 pages)
5. Theory Part A (1.5 pages)
6. Theory Part B (1.5 pages)
7. Conclusion (0.5 pages)
— Total: 9 pages
Theory papers often need 7 sections (splitting theory into estimation + optimization, or setup + analysis). The total page budget MUST sum to MAX_PAGES.
Theory papers should:
- Include **proof sketch** locations (not just theorem statements)
- Plan a **comparison table** of prior theoretical bounds vs. this paper's bounds
- Identify which proofs go in appendix vs. main body
**Method paper:**
1. Introduction (1.5 pages)
2. Related Work (1 page)
3. Method (2 pages)
4. Experiments (2.5 pages)
5. Ablation / Analysis (1 page)
6. Conclusion (0.5 pages)
Step 3: Section-by-Section Planning
For each section, specify:
### §0 Abstract
- **What we achieve**: [the paper's specific contribution, not field-level background]
- **Why it matters / is hard**: [why this problem is important and non-trivial]
- **How we do it**: [approach in one sentence]
- **Evidence**: [what supports the claim]
- **Most remarkable result**: [strongest quantitative or theoretical result]
- **Estimated length**: 150-250 words
- **Self-contained check**: can a reader understand this without the paper?
### §1 Introduction
- **Opening hook**: [1-2 sentences that motivate the problem]
- **Gap / challenge**: [what's missing in prior work, and why prior work is insufficient]
- **One
Read more
name: aris-paper-plan description: "Generate a structured paper outline from review conclusions and experiment results. Use when user says \"写大纲\", \"paper outline\", \"plan the paper\", \"论文规划\", or wants to create a paper plan before writing." argument-hint: "[topic-or-narrative-doc]" allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, Agent, WebSearch, WebFetch, mcp__codex__codex, mcp__codex__codex-reply license: MIT metadata: author: wanshuiyin/ARIS version: "1.0.0"
Paper Plan: From Review Conclusions to Paper Outline
Generate a structured, section-by-section paper outline from: **$ARGUMENTS**
Constants
- **REVIEWER_MODEL = `gpt-5.4`** — Model used via Codex MCP for outline review. Must be an OpenAI model.
- **TARGET_VENUE = `ICLR`** — Default venue. User can override (e.g., `/aris-paper-plan "topic" — venue: NeurIPS`). Supported: `ICLR`, `NeurIPS`, `ICML`, `CVPR`, `ACL`, `AAAI`, `ACM`, `IEEE_JOURNAL` (IEEE Transactions / Letters), `IEEE_CONF` (IEEE conferences).
- **MAX_PAGES** — Page limit. For ML conferences: main body to Conclusion end (excluding references, appendix). ICLR=9, NeurIPS=9, ICML=8. **For IEEE venues: references ARE included in page count.** IEEE journal Transactions ≈ 12-14 pages total, Letters ≈ 4-5 pages total; IEEE conference ≈ 5-8 pages total (including references).
Inputs
The skill expects one or more of these in the project directory:
1. **NARRATIVE_REPORT.md** or **STORY.md** — research narrative with claims and evidence 2. **GPT54_AUTO_REVIEW.md** — auto-review loop conclusions 3. **Experiment results** — JSON files in `figures/`, screen logs, tables 4. **IDEA_REPORT.md** — from idea-discovery pipeline (if applicable) 5. **Compact files** (if available): `IDEA_CANDIDATES.md`, `findings.md`, `EXPERIMENT_LOG.md` — preferred over full files when present, saves context window
If none exist, ask the user to describe the paper's contribution in 3-5 sentences.
Orchestra-Guided Writing Overlay
Keep the existing `insleep` workflow and outputs, but use the shared references below to improve the quality of the story and outline.
- Read `../shared-references/writing-principles.md` when framing the one-sentence contribution, Abstract, Introduction, Related Work, or hero figure.
- Read `../shared-references/venue-checklists.md` before freezing the outline for a specific venue.
- Only load these references when needed; do not paste their full contents into the working draft.
Workflow
Step 1: Extract Claims and Evidence
**First check for `CLAIMS_FROM_RESULTS.md`** — if it exists (generated by `/aris-result-to-claim` at the end of Workflow 2), use it as the starting point for claims. This file contains validated claims already mapped to experiment evidence. Merge with any additional claims from the narrative documents below.
If `CLAIMS_FROM_RESULTS.md` does not exist, extract claims from scratch:
Read all available narrative documents and extract:
1. **Core claims** (3-5 main contributions) 2. **One-sentence contribution** (the single sentence that best states what the paper contributes) 3. **Evidence** for each claim (which experiments, which metrics, which figures) 4. **Known weaknesses** (from reviewer feedback) 5. **Suggested framing** (from review conclusions)
Build a **Claims-Evidence Matrix**:
| Claim | Evidence | Status | Section | |-------|----------|--------|---------| | [claim 1] | [exp A, metric B] | Supported | §3.2 | | [claim 2] | [exp C] | Partially supported | §4.1 |
Step 2: Determine Paper Type and Structure
Based on TARGET_VENUE and paper content, classify and select structure.
Before committing to a structure, apply the narrative principle from `../shared-references/writing-principles.md`:
- The paper should tell one coherent technical story.
- By the end of the Introduction, the outline should make the **What**, **Why**, and **So What** explicit.
- Front-load the most important material: title, abstract, introduction, and hero figure. Reviewers often form a judgment before reading the full method.
**IMPORTANT**: The section count is FLEXIBLE (5-8 sections). Choose what fits the content best. The templates below are starting points, not rigid constraints.
**Empirical/Diagnostic paper:**
1. Introduction (1.5 pages) 2. Related Work (1 page) 3. Method / Setup (1.5 pages) 4. Experiments (3 pages) 5. Analysis / Discussion (1 page) 6. Conclusion (0.5 pages)
**Theory + Experiments paper:**
1. Introduction (1.5 pages) 2. Related Work (1 page) 3. Preliminaries & Modeling (1.5 pages) 4. Experiments (1.5 pages) 5. Theory Part A (1.5 pages) 6. Theory Part B (1.5 pages) 7. Conclusion (0.5 pages) — Total: 9 pages
Theory papers often need 7 sections (splitting theory into estimation + optimization, or setup + analysis). The total page budget MUST sum to MAX_PAGES.
Theory papers should:
- Include **proof sketch** locations (not just theorem statements)
- Plan a **comparison table** of prior theoretical bounds vs. this paper's bounds
- Identify which proofs go in appendix vs. main body
**Method paper:**
1. Introduction (1.5 pages) 2. Related Work (1 page) 3. Method (2 pages) 4. Experiments (2.5 pages) 5. Ablation / Analysis (1 page) 6. Conclusion (0.5 pages)
Step 3: Section-by-Section Planning
For each section, specify:
### §0 Abstract - **What we achieve**: [the paper's specific contribution, not field-level background] - **Why it matters / is hard**: [why this problem is important and non-trivial] - **How we do it**: [approach in one sentence] - **Evidence**: [what supports the claim] - **Most remarkable result**: [strongest quantitative or theoretical result] - **Estimated length**: 150-250 words - **Self-contained check**: can a reader understand this without the paper? ### §1 Introduction - **Opening hook**: [1-2 sentences that motivate the problem] - **Gap / challenge**: [what's missing in prior work, and why prior work is insufficient] - **One
A Super AI Lab with massive AI Doctors as Assistants. Best IDE for Research via AI Power.
Repo: OpenLAIR/dr-claw
Other skills on dr-claw.
- /dr-claw
Dr. Claw skill for OpenClaw project discovery, idea intake, waiting-session triage, structured session control, event-driven notifications, and mobile reporting through the local drclaw CLI.
Open skill - /academic-researcher
Academic research assistant for literature reviews, paper analysis, and scholarly writing. Use when: reviewing academic papers, conducting literature reviews, writing research summaries, analyzing methodologies, formatting citations, or when user mentions academic research,
Open skill - /autogpt
Autonomous AI agent platform for building and deploying continuous agents. Use when creating visual workflow agents, deploying persistent autonomous agents, or building complex multi-step AI automation systems.
Open skill - /crewai
Multi-agent orchestration framework for autonomous AI collaboration. Use when building teams of specialized agents working together on complex tasks, when you need role-based agent collaboration with memory, or for production workflows requiring sequential/hierarchical
Open skill - /langchain
Framework for building LLM-powered applications with agents, chains, and RAG. Supports multiple providers (OpenAI, Anthropic, Google), 500+ integrations, ReAct agents, tool calling, memory management, and vector store retrieval. Use for building chatbots, question-answering
Open skill - /llamaindex
Data framework for building LLM applications with RAG. Specializes in document ingestion (300+ connectors), indexing, and querying. Features vector indices, query engines, agents, and multi-modal support. Use for document Q&A, chatbots, knowledge retrieval, or building RAG
Open skill

