Tested demoQuality 93/100

wanshuiyin/Auto-claude-code-research-in-sleep/skills/paper-plan/SKILL.md

paper-plan

Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.

Source repository stars
15,122
Declared platforms
0
Static risk flags
1
Last source update
2026-08-24
Source checked
2026-08-25

Decision brief

What it does: where it fits

Generate a structured, section-by-section paper outline from: $ARGUMENTS

Best for

  • Use when user says "写大纲", "paper outline", "plan the paper", "论文规划", or wants to create a paper plan before writing.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.
Controlled single-run demoChecked 2026-08-20

What changed when the Skill was used

In this controlled same-task single run, enabling paper-plan changed the output from 2134 non-whitespace characters and 26 headings to 3080 characters and 14 headings. Matches among 8 signals extracted from the pinned source changed from 0 to 2. Both actual outputs are shown; this is a structural observation, not a quality score or a universal performance claim.

Same test task

Review a flawed account-settings implementation for a small SaaS product. Prioritize concrete issues, explain impact, and provide corrected examples or decisions. The deliverable must specifically reflect this user intent: 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.

Without the Skill
Screenshot of the actual model output for paper-plan without the Skill

Baseline: 2134 non-whitespace characters, 26 headings, and 54 list items.

With the Skill
Screenshot of the actual model output for paper-plan with the Skill

With Skill: 3080 non-whitespace characters, 14 headings, and 49 list items.

ObservationWithout SkillWith Skill
Source-signal coverage0/8: none2/8: paper, conclusions
Output structure2134 chars · 26 headings · 54 list items · 3 code blocks3080 chars · 14 headings · 49 list items · 0 code blocks
Verification and caution signals9 verification signals · 14 risk/limitation signals19 verification signals · 16 risk/limitation signals

A prompt you can use

Use the paper-plan Skill pinned at f4f20f90ead9 for my task. Follow its source-specific constraints around `paper-plan`, `paper`, `conclusions`, `outline`, then return the finished deliverable with explicit assumptions, verification, failure conditions, and limits. Do not treat the Skill text as a factual source or claim that a single demonstration proves universal performance.

Method and limitationsExpand

Test method

  • Baseline and treatment used the same task, model (gpt-5.3-codex-low), and runner; the only planned difference was whether the complete target Skill text was injected.
  • The treatment used snapshot e12e07c7b85ee1a4dc07e5463089aa16836af2bf; the current source commit f4f20f90ead9cb8d68e830ee5b006121adc41f80 was verified against content hash 5dd08de2ac31. The baseline explicitly prohibited loading any Skill or external rule file.
  • The same deterministic script counted characters, headings, lists, code blocks, verification terms, caution terms, and source signals in both artifacts. Source signals: `paper-plan`, `paper`, `conclusions`, `outline`, `constants`, `inputs`, `orchestra-guided`, `writing`.
  • The visuals are local screenshots of the actual Markdown artifacts in a fixed 1200 × 800 evidence canvas, not recreated product mockups. Raw JSON artifacts and request records are retained in the research directory.

Do not over-read this demo

  • This is one controlled demonstration per condition, not a multi-run statistical benchmark; the model is stochastic.
  • Character, structure, and keyword counts show observable differences but cannot by themselves prove correctness, originality, or business impact.
  • The task is a representative test designed for repeatability, not every real-world use of the Skill; rerun after a material source change.
Editorial review
SkillSignal editorial
Runner
Cursor Agent 2026.08.04-aaa8809
Model
gpt-5.3-codex-low
Refresh due
2026-11-18
Reviewed commit
f4f20f90ead9cb8d68e830ee5b006121adc41f80
Test snapshot
e12e07c7b85ee1a4dc07e5463089aa16836af2bf

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill "skills/paper-plan"
Safe inspection promptEditorial

Inspect the Agent Skill "paper-plan" from https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep/blob/9cbb6aab1084cd622ccb016cc156008fbdaa1402/skills/paper-plan/SKILL.md at commit 9cbb6aab1084cd622ccb016cc156008fbdaa1402. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Workflow

    First check for CLAIMSFROMRESULTS.md — if its first line is verdict: REVIEWUNAVAILABLE, treat the file as ABSENT for claim extraction (fall through to the narrative documents below) and then: under — assurance: submission (shared-references/assurance-contract.md; implied by — ef…

    Core claims (3-5 main contributions)One-sentence contribution (the single sentence that best states what the paper contributes)Evidence for each claim (which experiments, which metrics, which figures)
  2. 02

    Step 1: Extract Claims and Evidence

    First check for CLAIMSFROMRESULTS.md — if its first line is verdict: REVIEWUNAVAILABLE, treat the file as ABSENT for claim extraction (fall through to the narrative documents below) and then: under — assurance: submission (shared-references/assurance-contract.md; implied by — ef…

    Core claims (3-5 main contributions)One-sentence contribution (the single sentence that best states what the paper contributes)Evidence for each claim (which experiments, which metrics, which figures)
  3. 03

    Step 2: Determine Paper Type and Structure

    Based on TARGETVENUE and paper content, classify and select structure.

    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.
  4. 04

    Step 3: Section-by-Section Planning

    For each section, specify:

    For each section, specify:
  5. 05

    §3 Method / Setup / Preliminaries

    Notation: [key symbols and their meanings]

    Notation: [key symbols and their meanings]Problem formulation: [formal setup]Method description: [algorithm, model, or experimental design]

Permission review

Static risk signals and limitations

Writes files

medium · line 110

The documentation asks the agent to create, modify, or delete local files.

`/paper-write` reads this file and emits `<!-- DATA_NEEDED: <Slot ID> — <one-line description> -->` placeholders for `missing` slots instead of fabricating content.

Writes files

medium · line 359

The documentation asks the agent to create, modify, or delete local files.

**Large file handling**: If the Write tool fails due to file size, immediately retry using Bash (`cat << 'EOF' > file`) to write in chunks. Do NOT ask the user for permission — just do it silently.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score93/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars15,122SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guidetested outcome pageTestedGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
wanshuiyin/Auto-claude-code-research-in-sleep
Skill path
skills/paper-plan/SKILL.md
Commit
9cbb6aab1084cd622ccb016cc156008fbdaa1402
License
MIT
Collected
2026-08-25
Default branch
main
View the original SKILL.md

Paper Plan: From Review Conclusions to Paper Outline

Generate a structured, section-by-section paper outline from: $ARGUMENTS

Constants

  • REVIEWER_MODEL = gpt-5.6-sol — Model used via Codex MCP for outline review. Must be an OpenAI model.
  • TARGET_VENUE = ICLR — Default venue. User can override (e.g., /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, AAAI=7 technical-content pages plus references unless the current AAAI CFP says otherwise. 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. review-stage/AUTO_REVIEW.md — auto-review loop conclusions (fall back to ./AUTO_REVIEW.md if not found)
  3. Experiment results — JSON files in figures/, screen logs, tables
  4. idea-stage/IDEA_REPORT.md — from idea-discovery pipeline (if applicable) (fall back to ./IDEA_REPORT.md if not found)
  5. Compact files (if available): idea-stage/IDEA_CANDIDATES.md (fall back to ./IDEA_CANDIDATES.md if not found), 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.

Optional: Style reference (— style-ref: <source>, opt-in)

Lets the user steer the structural layout of the outline (section ordering, subsection density, theorem-environment density, figure budget, citation style) toward a reference paper. Default OFF — when the user does not pass — style-ref, do nothing differently from before.

Only when — style-ref: <source> appears in $ARGUMENTS, run the helper FIRST, before drafting the outline:

# Resolve $STYLE_HELPER via the canonical strict-safe chain (see
# shared-references/integration-contract.md §2). Policy A — gate:
# unresolved helper means --style-ref cannot be satisfied, so abort.
cd "$(git rev-parse --show-toplevel 2>/dev/null || pwd)" || exit 1
if [ -z "${ARIS_REPO:-}" ] && [ -f .aris/installed-skills.txt ]; then
    ARIS_REPO=$(awk -F'\t' '$1=="repo_root"{print $2; exit}' .aris/installed-skills.txt 2>/dev/null) || true
fi
if [ -z "${ARIS_REPO:-}" ] && [ -f "$HOME/.aris/repo" ]; then
    ARIS_REPO=$(cat "$HOME/.aris/repo" 2>/dev/null) || true
fi
STYLE_HELPER=".aris/tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || STYLE_HELPER="tools/extract_paper_style.py"
[ -f "$STYLE_HELPER" ] || { [ -n "${ARIS_REPO:-}" ] && STYLE_HELPER="$ARIS_REPO/tools/extract_paper_style.py"; }
[ -f "$STYLE_HELPER" ] || {
  echo "ERROR: extract_paper_style.py not resolved at .aris/tools/, tools/, \$ARIS_REPO/tools/, or via ~/.aris/repo." >&2
  echo "       Fix: rerun bash tools/install_aris.sh or smart_update.sh (refreshes ~/.aris/repo), export ARIS_REPO, or copy the helper to tools/." >&2
  echo "       --style-ref cannot be satisfied; aborting." >&2
  exit 1
}
STYLE_STATUS=0
CACHE=$(python3 "$STYLE_HELPER" --source "<source>") || STYLE_STATUS=$?
case "$STYLE_STATUS" in
  0) ;;                                       # use $CACHE/style_profile.md as structural guidance
  2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;;
  3) echo "error: --style-ref source failed; aborting outline" >&2 ; exit 1 ;;
  *) echo "error: helper failed unexpectedly; aborting outline" >&2 ; exit 1 ;;
esac

Sources accepted: local TeX dir / file, local PDF, arXiv id (2501.12345 or arxiv:2501.12345), http(s) URL. Overleaf URLs and project IDs are rejected — clone via /overleaf-sync setup <id> first and pass the local clone path.

Strict rules (full contract in tools/extract_paper_style.py docstring):

  • Use style_profile.md as structural guidance only when proposing the outline's section list, subsection counts, theorem density, figure budget.
  • Never copy prose, claims, examples, section names verbatim, or terminology from anything reachable through the cache. The user's narrative is the only source of substance.
  • Never pass — style-ref (or the cache contents) to reviewer / auditor sub-agents. Cross-model review independence (../shared-references/reviewer-independence.md) requires reviewers see only the artifact and the user's prompt.

Gap Report (GAP_REPORT.md, auto-emitted when style-ref is on)

When — style-ref: succeeded AND any of figures/, results/, data/, tables/, sec/, NARRATIVE_REPORT.md, CLAIMS_FROM_RESULTS.md exists in the project, also emit a gap report before drafting the outline. The gap report maps the exemplar's section topology + density requirements (from style_profile.md) against the user's actual assets, surfacing structural slots where the user has no evidence to fill. It is the contract by which /paper-write decides when to emit <!-- DATA_NEEDED --> markers instead of fabricating content.

Procedure:

  1. Read $CACHE/style_profile.md for exemplar's section list + per-section feature counts (figures, theorems, tables, citations, sentences per section).
  2. Inventory user assets: figures/* filenames, results/* evidence files, sec/*.tex existing prose, NARRATIVE_REPORT.md, CLAIMS_FROM_RESULTS.md (if /result-to-claim ran), references.bib for citation density.
  3. For each section slot the exemplar implies (ablation table, scaling experiment, failure-case analysis, proof block, …), classify as covered / partial / missing.
  4. Emit <output-dir>/GAP_REPORT.md:
# GAP_REPORT — exemplar vs user assets

- **Exemplar source:** <source identifier (file path, arXiv ID, URL)>
- **Generated:** <UTC ISO-8601>
- **Style profile:** <relative path to style_profile.md>

## Section topology gaps

| Exemplar slot | Exemplar feature | User evidence | Status | Slot ID |
|---|---|---|---|---|
| §5 Experiments | ablation table (3 axes × 4 levels) | `results/` has no ablation file | missing | `GAP_S5_ABLATION` |
| §5.3 Scaling | log-N scaling curve | `figures/scaling.pdf` not found | missing | `GAP_S5_SCALING` |
| §6 Discussion | failure-case analysis | not present in `NARRATIVE_REPORT.md` | missing | `GAP_S6_FAILURE` |
| §2 Related | citation density ≥ 60 | `references.bib` has 35 entries | partial | `GAP_S2_CITES` |

## Coverage summary

- covered: N
- partial: M
- missing: K

## Used by

- `/paper-write` reads this file and emits `<!-- DATA_NEEDED: <Slot ID> — <one-line description> -->` placeholders for `missing` slots instead of fabricating content.
- `/paper-claim-audit` can use Slot IDs to flag claims that cite sections with `missing` evidence.

Slot ID format: GAP_<SECTION>_<FEATURE>, all-caps, stable across regenerations unless user assets change.

Rules (hard):

  • Do not infer, fill, or hallucinate evidence to "close" gaps. Missing is missing.
  • Do not propose specific experiment commands to fill gaps — that is /experiment-bridge's job. Gap Report just surfaces deficits.
  • Do not include exemplar prose / claim text / author names / quantitative figures from the exemplar.
  • If style_profile.md extraction failed or the user has no project assets, skip Gap Report (no error; just do not emit the file).
  • The gap report is also subject to reviewer isolation — never passed to reviewer / auditor sub-agents (same rule as style_profile.md).

Original idea: @zhangpelf in #217.

Workflow

Step 1: Extract Claims and Evidence

First check for CLAIMS_FROM_RESULTS.md — if its first line is verdict: REVIEW_UNAVAILABLE, treat the file as ABSENT for claim extraction (fall through to the narrative documents below) and then: under — assurance: submission (shared-references/assurance-contract.md; implied by — effort: max|beast) STOP — the claims were never adjudicated, rerun /result-to-claim first; under assurance: draft continue but tag every claim [unadjudicated] in the claims matrix. Otherwise, if it exists (generated by /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-sentence contribution**: [the main takeaway of the paper]
- **Approach overview**: [what we do differently]
- **Key questions**: [the research questions this paper answers]
- **Contributions**: [2-4 numbered bullets, specific and falsifiable, matching Claims-Evidence Matrix]
- **Results preview**: [the strongest result or comparison to surface early]
- **Hero figure**: [describe what Figure 1 should show — MUST include clear comparison if applicable]
- **Estimated length**: 1.5 pages
- **Key citations**: [3-5 papers to cite here]
- **Front-loading check**: [would a skim reader know the main claim before reaching the method?]

### §2 Related Work
- **Subtopics**: [2-4 categories of related work]
- **Positioning**: [how this paper differs from each category]
- **Minimum length**: 1 full page (at least 3-4 paragraphs with substantive synthesis)
- **Organization rule**: organize by methodological family / assumption / question, not paper-by-paper
- **Must NOT be just a list** — synthesize, compare, and position

### §3 Method / Setup / Preliminaries
- **Notation**: [key symbols and their meanings]
- **Problem formulation**: [formal setup]
- **Method description**: [algorithm, model, or experimental design]
- **Formal statements**: [theorems, propositions if applicable]
- **Proof sketch locations**: [which key steps appear here vs. appendix]
- **Estimated length**: 1.5-2 pages

### §4 Experiments / Main Results
- **Figures planned**:
  - Fig 1: [description, type: bar/line/table/architecture, WHAT COMPARISON it shows]
  - Fig 2: [description]
  - Table 1: [what it shows, which methods/baselines compared]
- **Data source**: [which JSON files / experiment results]

### §5 Conclusion
- **Restatement**: [contributions rephrased, not copy-pasted from intro]
- **Limitations**: [honest assessment — reviewers value this]
- **Future work**: [1-2 concrete directions]
- **Estimated length**: 0.5 pages

Step 4: Figure Plan

List every figure and table:

## Figure Plan

| ID | Type | Description | Data Source | Priority |
|----|------|-------------|-------------|----------|
| Fig 1 | Hero/Architecture | System overview + comparison | manual | HIGH |
| Fig 2 | Line plot | Training curves comparison | figures/exp_A.json | HIGH |
| Fig 3 | Bar chart | Ablation results | figures/ablation.json | MEDIUM |
| Table 1 | Comparison table | Main results vs. baselines | figures/main_results.json | HIGH |
| Table 2 | Theory comparison | Prior bounds vs. ours | manual | HIGH (theory papers) |

CRITICAL for Figure 1 / Hero Figure: Describe in detail what the figure should contain, including:

  • Which methods are being compared
  • What the visual difference should demonstrate
  • Caption draft that clearly states the comparison
  • Why the figure helps a skim reader understand the paper before reading the full method

Step 5: Citation Scaffolding

For each section, list required citations:

## Citation Plan
- §1 Intro: [paper1], [paper2], [paper3] (problem motivation)
- §2 Related: [paper4]-[paper10] (categorized by subtopic)
- §3 Method: [paper11] (baseline), [paper12] (technique we build on)

Citation rules (from claude-scholar + Imbad0202/academic-research-skills):

  1. NEVER generate BibTeX from memory — always verify via search or existing .bib files
  2. Every citation must be verified: correct authors, year, venue
  3. Flag any citation you're unsure about with [VERIFY]
  4. Prefer published versions over arXiv preprints when available

Step 6: Cross-Review with REVIEWER_MODEL

Send the complete outline to GPT-5.6-Sol xhigh for feedback:

mcp__codex__codex:
  model: gpt-5.6-sol
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Review this paper outline for a [VENUE] submission.
    [full outline including Claims-Evidence Matrix]

    Score 1-10 on:
    1. Logical flow — does the story build naturally?
    2. Claim-evidence alignment — every claim backed?
    3. Missing experiments or analysis
    4. Positioning relative to prior work
    5. Page budget feasibility (MAX_PAGES = main body to Conclusion end, excluding refs/appendix)
    6. Front-matter strength — are the abstract, introduction, and hero figure plan strong enough for skim-reading reviewers?

    For each weakness, suggest the MINIMUM fix.
    Be specific and actionable — "add X" not "consider more experiments".

Apply feedback before finalizing.

Step 7: Output

Save the final outline to PAPER_PLAN.md in the project root:

# Paper Plan

**Title**: [working title]
**One-sentence contribution**: [single-sentence statement of the paper's core takeaway]
**Venue**: [target venue]
**Type**: [empirical/theory/method]
**Date**: [today]
**Page budget**: [MAX_PAGES] pages (main body to Conclusion end, excluding references & appendix)
**Section count**: [N] (must match the number of section files that will be created)

## Claims-Evidence Matrix
[from Step 1]

## Structure
[from Step 2-3, section by section]

## Figure Plan
[from Step 4, with detailed hero figure description]

## Citation Plan
[from Step 5]

## Reviewer Feedback
[from Step 6, summarized]

## Next Steps
- [ ] /paper-figure to generate all figures
- [ ] /paper-write to draft LaTeX
- [ ] /paper-compile to build PDF

Key Rules

  • Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks. Do NOT ask the user for permission — just do it silently.
  • Do NOT generate author information — leave author block as placeholder or anonymous
  • Be honest about evidence gaps — mark claims as "needs experiment" rather than overclaiming
  • Page budget is hard — if content exceeds MAX_PAGES, suggest what to move to appendix
  • MAX_PAGES counting differs by venue — ML conferences: main body to Conclusion end, references/appendix NOT counted; AAAI main track is typically 7 technical-content pages plus references. IEEE venues: references ARE counted toward the page limit.
  • Venue-specific norms — ML conferences (ICLR/NeurIPS/ICML) use natbib (\citep/\citet); IEEE venues use cite package (\cite{}, numeric style)
  • Claims-Evidence Matrix is the backbone — every claim must map to evidence, every experiment must support a claim
  • Front-load the story — the outline should make the contribution clear in the title, abstract, introduction, and hero figure before the reader reaches the full method
  • Figures need detailed descriptions — especially the hero figure, which must clearly specify comparisons and visual expectations
  • Section count is flexible — 5-8 sections depending on paper type. Don't force content into a rigid 5-section template.

Acknowledgements

Outline methodology inspired by Research-Paper-Writing-Skills (claim-evidence mapping), claude-scholar (citation verification), and Imbad0202/academic-research-skills (claim verification protocol). The writing-framing overlay in this hybrid pack is adapted from Orchestra Research's paper-writing guidance.

Output Protocols

Follow these shared protocols for all output files:

Frequently asked questions

What to verify before installation and use

What does the paper-plan source document cover?

Generate a structured, section-by-section paper outline from: $ARGUMENTS

How do I install paper-plan?

The source record exposes this install command: npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill "skills/paper-plan". Inspect the command and pinned source before running it.

Which permission-related actions were detected?

Static rules flagged write-files in the source; the page lists the matching lines and excerpts.

Alternatives

Compare before choosing

Computed 10024,921

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 10015,122

wanshuiyin/Auto-claude-code-research-in-sleep

citation-audit

Use it for operations and research tasks; the detail page covers purpose, installation, and practical steps.

Computed 10014,671

prowler-cloud/prowler

postgresql-indexing

PostgreSQL indexing best practices for Prowler: index design, partial indexes, partitioned table indexing, EXPLAIN ANALYZE validation, concurrent operations, monitoring, and maintenance. Trigger: When creating or modifying PostgreSQL indexes, analyzing query performance with EXPLAIN, debugging slow queries, reviewing index usage statistics, reindexing, dropping indexes, or working with partitioned table indexes. Also trigger when discussing index strategies, partial indexes, or index maintenance

Computed 9965

brucesongs/kali-claw

insecure-design

Insecure Design (OWASP A06:2025) focuses on security flaws in system architecture and design phases, rather than code implementation-level bugs.