Pipeline de rédaction d'articles ML

VérifiéSûr

Pipeline complet pour produire des articles de recherche ML/AI prêts à soumettre, de la conception à la révision.

Spar Skills Guide Bot
ContenuAvancé
25/07/2026
Claude CodeCodex
#research-paper#latex#ml-research#citations#experiment-design

Recommandé pour

Synthèse automatique

Pilote la production d'un article de recherche en ML/AI, de la conception d'expériences à la soumission en passant par l'analyse, la rédaction LaTeX et la relecture.

Points forts

  • Couvre tout le cycle de vie en boucle itérative plutôt qu'en pipeline linéaire : les résultats relancent des expériences, les reviews relancent l'analyse et la rédaction.
  • Traite la vérification des citations de façon programmatique (Semantic Scholar, arXiv, habanero) et impose un marquage [CITATION NEEDED] au lieu d'inventer des références.
  • Exige que chaque expérience soit explicitement reliée à une affirmation du papier, ce qui garde l'article centré sur une contribution unique.
  • Prévoit aussi les cas non empiriques : papiers théoriques, surveys, benchmarks, papiers de position et évaluations humaines.

Limites

  • Suppose un environnement terminal avec LaTeX et une longue liste de dépendances Python installées ; rien ne fonctionne sans cela.
  • Ne produit pas le code d'entraînement : le routage précise que le développement logiciel et le design visuel sont hors périmètre et relèvent d'un autre agent.
  • Le cadre reste générique par rapport au template exact de chaque conférence, les contraintes de format doivent être revérifiées à la main avant envoi.
Quand l'utiliser

À mobiliser dès qu'on part d'une idée ou d'un codebase existant pour produire un article destiné à NeurIPS, ICML, ICLR, ACL, AAAI ou COLM, jusqu'à la réponse aux reviews et la soumission.

Quand l'éviter

À éviter si l'objectif est d'implémenter les modèles ou les expériences, ou de rédiger un document technique non académique.

Analyse de sécurité

Sûr
Score qualité82/100

This is a research-paper-writing workflow skill. It declares no dangerous tools and its dependencies (arxiv, semanticscholar, habanero, requests, numpy, scipy, matplotlib, SciencePlots) are standard library/research packages used for literature search and plotting. There are no destructive commands, no curl|sh piping, no secret exfiltration, no base64 payloads, and no instructions to disable safety. It does note a terminal/files toolset requirement, but that is for legitimate experiment execution and file management. No meaningful execution risk.

Aucun point d'attention détecté

Comment cette analyse est faite

Exemples

Plan d'expériences et squelette
Starting from my repo at ~/code/flow-matching, design the experiment plan for a NeurIPS submission and scaffold the LaTeX paper with a one-sentence contribution statement.
Vérification des citations
Check every citation in my Related Work section against Semantic Scholar and arXiv, and replace anything you cannot verify with [CITATION NEEDED].
Réponse aux reviews
Draft the rebuttal for these reviewer comments: for each point, tell me whether it needs a new experiment or a text change, then write the response.

name: research-paper-writing title: Research Paper Writing Pipeline description: 'Write ML papers for NeurIPS/ICML/ICLR: design→submit.' version: 1.1.0 author: Orchestra Research license: MIT dependencies:

  • semanticscholar
  • arxiv
  • habanero
  • requests
  • scipy
  • numpy
  • matplotlib
  • SciencePlots platforms:
  • linux
  • macos metadata: hermes: tags: ['Research', 'Paper Writing', 'Experiments', 'ML', 'AI', 'NeurIPS', 'ICML', 'ICLR', 'ACL', 'AAAI', 'COLM', 'LaTeX', 'Citations', 'Statistical Analysis'] category: research related_skills: ['arxiv', 'ml-paper-writing', 'subagent-driven-development', 'plan'] requires_toolsets: ['terminal', 'files'] lane: worker-heavy reasoning_effort: xhigh agent: Researcher routing_hint: | Agent-Scope: Deep-research, fact-checking, paper-search, knowledge-base. Off-scope: code-building, visual design, writing — return to Yuno.

Routing-Spec: yuno-team-routing.


Research Paper Writing Pipeline

End-to-end pipeline for producing publication-ready ML/AI research papers targeting NeurIPS, ICML, ICLR, ACL, AAAI, and COLM. This skill covers the full research lifecycle: experiment design, execution, monitoring, analysis, paper writing, review, revision, and submission.

This is not a linear pipeline — it is an iterative loop. Results trigger new experiments. Reviews trigger new analysis. The agent must handle these feedback loops.

<!-- ascii-guard-ignore -->
┌─────────────────────────────────────────────────────────────┐
│                    RESEARCH PAPER PIPELINE                  │
│                                                             │
│  Phase 0: Project Setup ──► Phase 1: Literature Review      │
│       │                          │                          │
│       ▼                          ▼                          │
│  Phase 2: Experiment     Phase 5: Paper Drafting ◄──┐      │
│       Design                     │                   │      │
│       │                          ▼                   │      │
│       ▼                    Phase 6: Self-Review      │      │
│  Phase 3: Execution &           & Revision ──────────┘      │
│       Monitoring                 │                          │
│       │                          ▼                          │
│       ▼                    Phase 7: Submission               │
│  Phase 4: Analysis ─────► (feeds back to Phase 2 or 5)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

When To Use This Skill

Use this skill when:

  • Starting a new research paper from an existing codebase or idea
  • Designing and running experiments to support paper claims
  • Writing or revising any section of a research paper
  • Preparing for submission to a specific conference or workshop
  • Responding to reviews with additional experiments or revisions
  • Converting a paper between conference formats
  • Writing non-empirical papers — theory, survey, benchmark, or position papers
  • Designing human evaluations for NLP, HCI, or alignment research
  • Preparing post-acceptance deliverables — posters, talks, code releases

Core Philosophy

  1. Be proactive. Deliver complete drafts, not questions. Scientists are busy — produce something concrete they can react to, then iterate.
  2. Never hallucinate citations. AI-generated citations have ~40% error rate. Always fetch programmatically. Mark unverifiable citations as [CITATION NEEDED].
  3. Paper is a story, not a collection of experiments. Every paper needs one clear contribution stated in a single sentence. If you can't do that, the paper isn't ready.
  4. Experiments serve claims. Every experiment must explicitly state which claim it supports. Never run experiments that don't connect to the paper's narrative.
  5. Commit early, commit often. Every completed experiment batch, every paper draft update — commit with descriptive messages. Git log is the experiment history.

Proactivity and Collaboration

Default: Be proactive. Draft first, ask with the draft.

| Confidence Level | Action | |-----------------|--------| | High (clear repo, obvious contribution) | Write full draft, deliver, iterate on feedback | | Medium (some ambiguity) | Write draft with flagged uncertainties, continue | | Low (major unknowns) | Ask 1-2 targeted questions via clarify, then draft |

| Section | Draft Autonomously? | Flag With Draft | |---------|-------------------|-----------------| | Abstract | Yes | "Framed contribution as X — adjust if needed" | | Introduction | Yes | "Emphasized problem Y — correct if wrong" | | Methods | Yes | "Included details A, B, C — add missing pieces" | | Experiments | Yes | "Highlighted results 1, 2, 3 — reorder if needed" | | Related Work | Yes | "Cited papers X, Y, Z — add any I missed" |

Block for input only when: target venue unclear, multiple contradictory framings, results seem incomplete, explicit request to review first.


Phase Overview

Eight phases, each detailed in its own reference file. Each reference has the same heading convention: # Phase N: Title.

| # | Phase | Goal | Reference | |---|-------|------|-----------| | 0 | Project Setup | Establish workspace, identify contribution | phase0-setup.md | | 1 | Literature Review | Find papers, gather verified citations (never hallucinate BibTeX) | phase1-literature.md | | 2 | Experiment Design | Map claims → experiments, define baselines & evaluation protocol | phase2-experiment-design.md | | 3 | Execution & Monitoring | Run reliably, recover from failures, track via cron + journal | phase3-execution.md | | 4 | Result Analysis | Statistics, story, figures; write experiment_log.md as bridge to writing | phase4-analysis.md | | 5 | Paper Drafting | Narrative principle, sections, LaTeX preamble, TikZ, algorithm2e, latexdiff | phase5-drafting.md | | 6 | Self-Review & Revision | Ensemble + VLM + claim-verification passes; rebuttal writing | phase6-review.md | | 7 | Submission Preparation | Anonymize, validate, compile, submit; covers Phase 8 + workshop + paper types | phase7-submission.md |

Cross-cutting reference docs (used across phases)

Note: Diese cross-cutting reference docs sind als zukünftige Erweiterungen geplant. Die Inhalte zu writing quality, citations, checklists, reviewer guidelines, experiment patterns, autoreason, human evaluation, paper types und sources sind aktuell in den jeweiligen Phase-Referenzen (references/phaseN-*.md) inline eingebettet. Beim späteren Ausbau können diese Docs aus den Phase-Files extrahiert werden.

LaTeX templates live in templates/ (NeurIPS 2025, ICML 2026, ICLR 2026, ACL, AAAI 2026, COLM 2025). See templates/README.md for compilation setup.


Common Pitfalls (Top Warnings)

Never hallucinate citations. AI-generated BibTeX has ~40% error rate. Always fetch via DOI programmatically and mark unverifiable ones as [CITATION NEEDED].

Every experiment must map to a claim. No orphan experiments. If you can't point to the paper claim it supports, don't run it.

Read papers as a story, not a list. Related work is grouped by methodology, not paper-by-paper. ("One line of work uses X [refs] whereas we use Y because...")

Never copy LaTeX preambles between templates. When converting venues, start fresh from the target template and copy only content.

Commit experiments and drafts continuously. Git log is the experiment history. Use experiment_journal.jsonl to track the reasoning tree (hypothesis → result → next-step), not just file changes.

Simulated reviews need negative bias. LLMs default to positive; explicitly instruct reviewers to flag weaknesses and not give "the benefit of the doubt."

Verify every claim in the draft against the actual result files. Delegate this to a fresh sub-agent with no shared memory to prevent confirmation bias.

See references/phase6-review.md for the full review protocol and references/phase4-analysis.md for handling negative/null results.


Hermes Agent Integration

This skill is designed for the Hermes agent — uses terminal, process, execute_code, read_file/write_file/patch, web_search/web_extract, delegate_task, todo, memory, cronjob, clarify, and send_message.

Supersedes ml-paper-writing (all its content plus the experiment/analysis pipeline and autoreason methodology).

Related skills

| Skill | When to Use | How to Load | |-------|-------------|-------------| | arxiv | Phase 1: arXiv search, BibTeX, Semantic Scholar | skill_view("arxiv") | | subagent-driven-development | Phase 5: parallel section writing + 2-stage review | skill_view("subagent-driven-development") | | plan | Phase 0: structured plans before execution | skill_view("plan") | | qmd | Phase 1: local knowledge bases (BM25+vector) | skill_manage("install", "qmd") | | diagramming | Phase 4-5: Excalidraw architecture diagrams | skill_view("diagramming") | | data-science | Phase 4: Jupyter live kernel for analysis | skill_view("data-science") |

Standard patterns

Parallel section drafting — each delegate_task runs as a fresh subagent with no shared context; include all needed info in the prompt.

Experiment monitoring loop:

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '<msg>' && git push")
→ send_message("Experiment complete: <summary>")

Session startup: todo("list") → memory("read") → git log --oneline -10 → ps aux | grep python → ls results/ | tail -20 → report status.

Notify vs [SILENT]: notify on experiment completion / unexpected finding / draft ready / deadline approaching; stay [SILENT] for in-progress experiments and routine no-change checks.

Use patch (not write_file) for targeted edits to large .tex files.


Reviewer Evaluation Criteria

| Criterion | What They Check | |-----------|----------------| | Quality | Technical soundness, well-supported claims, fair baselines | | Clarity | Clear writing, reproducible by experts, consistent notation | | Significance | Community impact, advances understanding | | Originality | New insights (doesn't require new method) |

NeurIPS 6-point scale: 6 = Strong Accept → 1 = Strong Reject. See references/reviewer-guidelines.md for detailed guidelines and rebuttal strategies.


Common Issues (Quick Index)

| Issue | Where to fix it | |-------|---------| | Abstract too generic | phase5 § Step 5.1 — 5-sentence formula | | Introduction exceeds 1.5 pages | phase5 § Step 5.3 | | Experiments lack explicit claims | phase4 § Step 4.3 | | Reviewers find paper hard to follow | phase5 § Writing Style — Gopen & Swan, signposting | | Missing statistical significance | phase4 § Step 4.2 + experiment-patterns.md | | Scope creep in experiments | phase2 § Step 2.1 — claims-to-experiments map | | Paper rejected, need to resubmit | phase7 § Step 7.7 — never reference prior review | | Missing broader impact | phase5 § Step 5.10 | | Human eval criticized as weak | phase2 § Step 2.5 + human-evaluation.md | | Reviewers question reproducibility | phase7 § Step 7.10 — code packaging | | Theory paper lacks intuition | paper-types.md § Theory | | Results are negative/null | phase4 § Step 4.3 — handling negative results |


Key External Sources

Writing: Neel Nanda · Sebastian Farquhar · Gopen & Swan · Lipton · Perez

APIs: Semantic Scholar · CrossRef · arXiv

Venues: NeurIPS · ICML · ICLR · ACL

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/research-paper-writing-pipeline-mrzxuox4' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/research-paper-writing-pipeline-mrzxuox4/download' --output '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md.part' && mv '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md.part' '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md' && test -s '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/research-paper-writing' && cp -R '.skill-downloads/research-paper-writing-pipeline-mrzxuox4' '.claude/skills/research-paper-writing'

Codex
test -f '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md' && test -s '.skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/research-paper-writing' && cp -R '.skill-downloads/research-paper-writing-pipeline-mrzxuox4' '.agents/skills/research-paper-writing'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/research-paper-writing-pipeline-mrzxuox4'

openskills read 'research-paper-writing-pipeline-mrzxuox4'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/research-paper-writing-pipeline-mrzxuox4/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires