Mmcp.market

resubmit-pipeline skill

by wanshuiyin·wanshuiyin/Auto-claude-code-research-in-sleep·17k stars·MIT

Workflow 5: orchestrate a text-only resubmit of a polished paper to a different venue under hard constraints (no new experiments, no bib edits, no framework changes, never overwrite prior submissions). Use when user says \"resubmit pipeline\", \"重投流程\", \"port paper to <new venue>\", \"resubmit to <venue>\", \"tighten paper for resubmission\", or has a rejected/withdrawn paper to move to a different top venue under tight time budget.

A100/100content scan

Is the resubmit-pipeline skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the resubmit-pipeline skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep.git /tmp/Auto-claude-code-research-in-sleep
mkdir -p ~/.claude/skills
cp -r /tmp/Auto-claude-code-research-in-sleep/skills/resubmit-pipeline ~/.claude/skills/resubmit-pipeline
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Resubmit Pipeline: Text-Only Microedit Mode

Compose a polished paper into a new venue under text-only constraints: $ARGUMENTS

Why This Exists

Most ARIS writing workflows assume the input is either a narrative report (Workflow 3) or an in-progress paper that may still need experiments / bib changes / structural edits. Resubmit is a fundamentally different scope:

  • The paper is already polished — proofs are done, experiments are done, bibliography is curated.
  • The user wants to absorb prior reviewer concerns from a previous venue and re-submit, without introducing new experiments, new citations, or framework changes (LLM hallucination paranoia + tight resubmit timing + closed compute budget).
  • The base submission directory is read-only — the new submission must compose into a sibling directory, never mutate prior state.
  • Page limit may shrink between source and target venue (e.g., workshop camera-ready → 9-page main).

Existing skills cover adjacent territory but none of this exact composition: /rebuttal builds the OpenReview-style response document, not in-paper microedits; /auto-paper-improvement-loop is the per-round engine but presupposes someone has already chosen the base manuscript, migrated venue format, set the edit whitelist, queued the reviewer feedback, and decided what NOT to change. /resubmit-pipeline fills that orchestration gap.

When to Use

  • A theory or system paper was rejected at venue A and you want to resubmit to venue B with tight time budget (≤ 1-2 weeks).
  • You have 3 inputs ready: the polished paper directory at venue A's format, the target venue B's format/template/style files, and the prior reviewer reports.
  • You explicitly do not want to re-derive theorems, run new experiments, or change the bibliography.

When NOT to Use

  • The paper still needs experiments — use /experiment-bridge → /auto-review-loop first.
  • The paper still needs structural rewrites or new sections — use /paper-writing (Workflow 3).
  • You want to write the rebuttal response itself — use /rebuttal (Workflow 4).
  • The reviewer feedback demands new theorems or new framework — escalate to user before starting; this skill emits BLOCKED with reasoncode: outofscopemicroedit if it detects this case.

Constants

  • REVIEWERMODEL** = inherits from /auto-paper-improvement-loop's default (gpt-6-astra via Codex MCP) unless the user passes — reviewer-model: gpt-5.4 (legacy) or another OpenAI model. Codex reasoning effort is fixed at xhigh for all reviewer calls per the existing skill convention.
  • ROUNDS = 2 (default; matches /auto-paper-improvement-loop's diminishing-returns line). A 3rd round only fires if Phase 2 reports non-convergence AND the user explicitly approves at the round-2 checkpoint.
  • EFFORT = max (default for resubmit; resubmit is high-stakes). The user can override with — effort: balanced if time is extremely tight.
  • EDITWHITELISTPATH = /..//.aris/edit_whitelist.yaml (auto-generated in Phase 0; user can override with a custom path).
  • NEVEROVERWRITE** = true (always; this is a hard contract — prior submission directories are immutable).
  • ASSURANCELEVEL** = submission (default; resubmit always targets a real submission).

Inputs

Three mandatory inputs:

  1. paper-base-dir — the polished paper at venue A's format. Must contain main.tex (or equivalent entry), sec/ or sections/, references.bib (or equivalent), and a compiled main.pdf (used for visual review).
  2. — target-venue: — one of: iclr, icml, neurips, aaai, ijcai, colm, tmlr, uai, or other. The skill expects venue style files at /templates/.{sty,tex,bst} or in a recognized template directory. If other, the user passes — target-style-dir: .
  3. — review-corpus: — directory containing prior venue's reviewer reports as .txt or .md files (one per reviewer, ideally). If --review-corpus is omitted, the skill emits BLOCKED with reasoncode: missingreview_corpus because the whole point of resubmit is absorbing those concerns.

Optional:

  • — reviewer-model: gpt-5.4 — override the default reviewer (gpt-6-astra); use this for legacy reproducibility or to consume the older quota tier.
  • — rounds: — override default 2.
  • — assurance: draft — relax MANDATORY gates (default submission).
  • — effort: balanced — relax max if time is critical.
  • — skip-anonymity-scan — skip Phase 0.5 anonymity check (only valid for non-double-blind venues like TMLR; else WARN).
  • — overleaf-target: — the Overleaf project ID for Phase 4 push (per /overleaf-sync setup).

Pipeline

Phase 0: Physical Isolation Setup (zero edits to existing files)

Resubmit's hardest invariant: never overwrite any prior submission directory. The new venue's submission lives as a sibling of all prior venues.

# Resolve target-venue → new sibling dir name (capitalized)
NEW_VENUE_DIR="$(dirname "$PAPER_BASE_DIR")/$(echo "$TARGET_VENUE" | sed 's/.*/\u&/')"

# Atomic dir create — `mkdir` (not `mkdir -p`) fails fast if the dir exists,
# avoiding the TOCTOU race window of `[ -e ] && exit; mkdir -p`. The mkdir
# itself must succeed exactly once; if a concurrent run gets there first,
# this errors out per resubmit-pipeline's never-overwrite invariant.
mkdir "$NEW_VENUE_DIR" 2>/dev/null || {
    echo "ERROR: $NEW_VENUE_DIR already exists; resubmit-pipeline never overwrites prior submissions. Pick a different target-venue or rename the existing dir." >&2
    exit 1
}
mkdir -p "$NEW_VENUE_DIR/.aris"

Composition rules (all cp, never \input{../...}, never symlink):

  1. main.tex — write fresh for the target venue's .sty. Use templates/.tex as the starting skeleton; only the \title{}, \author{}, abstract include, and section input lines are copied from the base venue's main.tex. The new main.tex lives entirely inside $NEWVENUEDIR/.
  2. sec/ (or sections/) — physical cp -r $PAPERBASEDIR/sec/ $NEWVENUEDIR/sec/. Do not symlink, do not \input{../sec/...} from the new main. Symlinks break Overleaf zip export; cross-directory \input would mutate the shared pool and pollute prior submissions.
  3. mathcommands.tex (and any other macro file the sections depend on) — physical cp into $NEWVENUE_DIR/.
  4. Figure/ (or figures/) — copy the directory in (cp -r). Path trap: existing sections likely write \includegraphics{Figure/foo.pdf}. If you set \graphicspath{{../Figure/}} from a child directory, it resolves ../Figure/Figure/foo.pdf — wrong. Either copy Figure/ in directly (preferred), or use \graphicspath{{../}}.
  5. Bibliography — write \bibliographystyle{} + \bibliography{../references} directly in the new main.tex. Never \input an existing ref.tex or references.tex that already contains its own \bibliography{} command (path resolution silently breaks).
  6. .aris/ — create $NEWVENUEDIR/.aris/ and write assurance.txt containing submission (matches the verifier's expected location).

Output of Phase 0: a new sibling dir with all source files, no edits to text content yet, ready for compile.

Phase 0.5: Health Check + Anonymity Scan (still zero text edits)

Before any audit or edit, the paper must compile cleanly on the new venue's style and pass anonymity scan if the target venue is double-blind.

Compile + page count:

cd "$NEW_VENUE_DIR"
latexmk -C
latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex 2>&1 | tee compile.log

If compile fails: emit RESUBMITREPORT.json with verdict: BLOCKED, reasoncode: phase05compilefailed, surface the error to the user, and stop. Common causes: missing macro from math_commands.tex, venue style undefined command, \graphicspath issue.

Page count vs venue limit (measure first; do not assume):

PAGES=$(pdfinfo main.pdf | awk '/^Pages:/ {print $2}')
LIMIT=$(grep -oE "page_limit: [0-9]+" "$NEW_VENUE_DIR/templates/$TARGET_VENUE.tex" | awk '{print $2}')
echo "Pages: $PAGES, Limit: $LIMIT, Delta: $((PAGES - LIMIT))"

If PAGES > LIMIT, queue Phase 2 to honor a page-shrink heuristic (see "Page-Shrink Heuristic" below).

Anonymity scan (skip only if — skip-anonymity-scan is passed AND target venue is non-double-blind):

The scan covers 5 layers (the proposal's 1-layer scan was incomplete):

  1. Surface identifiers: author surnames, affiliations, institution names, lab codenames, prior funding tag IDs (grep -E "$(echo $AUTHOR_SURNAMES | tr ' ' '|')|$(echo $AFFILIATIONS | tr ' ' '|')").
  2. Self-citation phrasing: any sentence using "we showed in [...]" or "in our prior work [...]" that names the paper's own authors. Must rewrite to "X et al. [year] shows..." third-person form. Grep regex: \b(we|our|my|I)\s+(showed|proved|demonstrated|prior work|earlier paper|previous paper)\b.
  3. Acknowledgments + funding: scan acknowledgments.tex (or \acknowledgments{} block) for institution-specific thanks, grant IDs, named collaborators. Comment out for double-blind submission.
  4. Cross-rebuttal references: scan footnotes and body for "this paper builds on rebuttal at venue X" or "addressing reviewer N's concern from venue X" — these must be removed entirely (they violate anonymity AND signal prior rejection).
  5. Internal codenames / project links: grep for repo URLs (github.com//), Slack channel names, internal wiki links, and dataset codenames that may identify the lab.

If any of the 5 layers triggers a hit, emit RESUBMITREPORT.json with verdict: BLOCKED, reasoncode: anonymityscanfailed and present a per-hit list to the user. They must approve a fix or accept the risk before Phase 1 runs. Layers 4-5 are equally blocking as layers 1-3 — cross-rebuttal references and internal codenames signal both prior-venue identity AND lab identity, both of which violate double-blind in different ways.

Residual coloring / margin-note scan:

Search for \revise{...}, \fix{...}, \new{...}, \todo{...}, \todonotes{...}, \textcolor{red}{...} leftovers from camera-ready cycles. List them; user decides whether to keep (some venues accept revision-marker boxes) or strip.

Output of Phase 0.5: BASELINE.md with initial page count, anonymity-scan summary, residual-color list, overfull-hbox count.

Phase 1: Audit (zero edits)

Three audits in parallel, all detect-only. The new dir's source files are read; nothing is written except audit artifacts.

Critical: the third audit MUST run with — soft-only. Without that flag, citation-audit emits KEEP/FIX/REPLACE/REMOVE verdicts that presuppose bib mutations — incompatible with resubmit's "no bib edits" constraint. With --soft-only, the same findings are translated to per-occurrence sentence-rewrite proposals consumable by Phase 2.

Atomize prior reviewer concerns in parallel:

For each file under $REVIEW_CORPUS:
    Read the reviewer report.
    Atomize into discrete concerns: severity (critical / major / minor),
      type (assumption / novelty / scope / rigor / experiment-coverage / framing),
      addressability (text-fixable / partial / unaddressable-under-constraints).
    Append to KNOWN_WEAKNESSES.md with stable IDs (W1, W2, ...).

KNOWN_WEAKNESSES.md schema:

- id: W1
  severity: major
  type: scope
  source: reviewer_2_venue_a
  concern: "Theorem 3 states a generic result but the proof only handles a specific regime."
  addressability: text-fixable
  recommended_fix: "Narrow Theorem 3's title to 'restricted regime'; add scope qualifier in abstract."
- id: W2
  severity: critical
  type: experiment-coverage
  source: reviewer_3_venue_a
  concern: "No comparison against [prior method X]."
  addressability: unaddressable-under-constraints
  recommended_fix: "Acknowledge in Limitations that this comparison is left for future work."

Output of Phase 1: 4 artifacts (3 audits + KNOWN_WEAKNESSES.md). All are inputs to Phase 2.

Phase 2: Targeted Text Microedits via Auto-Improvement Loop

The load-bearing phase. /auto-paper-improvement-loop is invoked with two safety mechanisms:

  1. — edit-whitelist — a YAML file enumerating allowed paths and forbidden operations. Auto-generated in Phase 0 at $NEWVENUEDIR/.aris/edit_whitelist.yaml:
allowed_paths:
     - "sec/*.tex"
     - "main.tex"
     - "appendix.tex"
   forbidden_paths:
     - "**/*.bib"
     - "**/*.sty"
     - "**/*.bst"
     - "../*Submission/**"           # all prior submission dirs
     - "../*Camera/**"
     - "templates/**"
   forbidden_operations:
     - new_cite                       # blocks \cite{...}, \citep{...}, \citet{...}, \citeauthor{...}
     - new_bibitem                    # blocks \bibitem{...} additions
     - new_theorem_env                # blocks \begin{theorem|lemma|proposition|corollary} additions
     - numerical_claim                # blocks adding numbers / percentages / metrics not present in original
   rationale: "Resubmit mode: text-only microedits, paper structure frozen by user constraint."
  1. Per-round diff gate via auto-loop's HUMANCHECKPOINT — /auto-paper-improvement-loop does not accept --rounds, --reviewer-model, or --resume-after-round-checkpoint flags (those are not in its CLI). It uses the MAXROUNDS = 2 constant and REVIEWERMODEL = gpt-6-astra defaults, with an existing HUMANCHECKPOINT mechanism for round gating. Resubmit-pipeline therefore invokes the loop once with HUMAN_CHECKPOINT = true so each round pauses for the orchestrator to inspect the diff:
# Snapshot the new venue dir BEFORE auto-loop runs (for diff baseline,
   # works whether or not paper-base-dir is a git repo)
   SNAPSHOT_DIR="$NEW_VENUE_DIR/.aris/snapshots/round-0"
   mkdir -p "$SNAPSHOT_DIR"
   rsync -a --exclude='.aris' --exclude='*.pdf' --exclude='*.aux' \
         "$NEW_VENUE_DIR/" "$SNAPSHOT_DIR/"

   # Single auto-loop invocation; rounds + checkpoints are loop-internal.
   # The whitelist file is the only resubmit-specific param.
   /auto-paper-improvement-loop "$NEW_VENUE_DIR/" \
       --edit-whitelist "$NEW_VENUE_DIR/.aris/edit_whitelist.yaml" \
       — assurance: submission \
       — effort: "$EFFORT" \
       — human checkpoint: true

Inside the loop, at each round-end checkpoint, the resubmit orchestrator inspects:

for ROUND in 1 2; do  # auto-loop's MAX_ROUNDS = 2
     # auto-loop pauses at HUMAN_CHECKPOINT after each round
     # diff this round vs prior snapshot (works without git)
     diff -ruN "$NEW_VENUE_DIR/.aris/snapshots/round-$((ROUND-1))" "$NEW_VENUE_DIR" \
         > "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"

     # Whitelist compliance check on the diff
     check_whitelist_compliance "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt" \
                                  "$NEW_VENUE_DIR/.aris/edit_whitelist.yaml"

     # Selective regression audits (only fire if relevant files touched)
     if grep -qE 'theorem|lemma|proposition|corollary' "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"; then
         /proof-checker "$NEW_VENUE_DIR/main.tex" --restatement-check
     fi
     if grep -qE '[0-9]+(\.[0-9]+)?\s*(%|±|x|×)' "$NEW_VENUE_DIR/.aris/round-$ROUND-diff.txt"; then
         /paper-claim-audit "$NEW_VENUE_DIR/"
     fi

     # Snapshot this round for next-round diff
     rsync -a --exclude='.aris' --exclude='*.pdf' --exclude='*.aux' \
           "$NEW_VENUE_DIR/" "$NEW_VENUE_DIR/.aris/snapshots/round-$ROUND/"

     # Convergence check — see "Convergence Criteria" section below
     # 

Why the snapshot-rsync approach instead of git diff HEAD~1..HEAD: the paper-base-dir is not guaranteed to be a git repo, and even when it is, intermediate states inside one auto-loop round don't produce per-round commits. rsync snapshots are repo-agnostic.

  1. Mapping of edits to concerns — every proposed edit must be mapped to either (a) an entry in KNOWN_WEAKNESSES.md with an ID, OR (b) a Phase 1 audit finding. Un-mapped edits are rejected by the loop's reviewer prompt. This is enforced via the loop's reviewer prompt template (the resubmit-pipeline's invocation passes a custom prompt addendum saying "every fix must cite a W ID or audit finding ID").

Inputs into the loop's reviewer prompt (concatenated):

  • The 3 Phase 1 audit reports (PROOFAUDIT.md, PAPERCLAIMAUDIT.md, CITATIONAUDIT.md)
  • KNOWN_WEAKNESSES.md
  • A custom addendum: "you are reviewing a resubmit; the user constraint is text-only microedits; every proposed fix MUST cite either a W ID from KNOWN_WEAKNESSES or an audit finding ID; un-mapped fixes are rejected; the edit whitelist is binding."

Output of Phase 2: PAPERIMPROVEMENTLOG.md with per-round diffs, rejectedbyedit_whitelist list, and convergence status.

More skills from wanshuiyin/Auto-claude-code-research-in-sleep

  • Aablation-plannerUse when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
  • Aablation-plannerUse when main results pass result-to-claim (`claim_supported = yes` or `partial`) and ablation studies are needed for paper submission. A secondary Codex agent designs ablations from a reviewer's perspective; the local executor reviews feasibility and implements.
  • AalphaxivQuick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this paper", "summarize paper", pastes an arXiv/AlphaXiv URL, or provides a bare arXiv ID for quick understanding - not for broad literature search.
  • AalphaxivQuick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this paper", "summarize paper", pastes an arXiv/AlphaXiv URL, or provides a bare arXiv ID for quick understanding - not for broad literature search.
  • Aanalyze-resultsAnalyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says "analyze results", "compare", or needs to interpret experimental data.
  • Aanalyze-resultsAnalyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says \"analyze results\", \"compare\", or needs to interpret experimental data.
  • AarxivSearch, download, and summarize academic papers from arXiv. Use when user says "search arxiv", "download paper", "fetch arxiv", "arxiv search", "get paper pdf", or wants to find and save papers from arXiv to the local paper library.
  • AarxivSearch, download, and summarize academic papers from arXiv. Use when user says \"search arxiv\", \"download paper\", \"fetch arxiv\", \"arxiv search\", \"get paper pdf\", or wants to find and save papers from arXiv to the local paper library.
  • Aauto-paper-improvement-loopAutonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
  • Aauto-paper-improvement-loopAutonomously improve a generated paper via Claude review through claude-review MCP → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
  • Aauto-paper-improvement-loopAutonomously improve a generated paper via Gemini review through gemini-review MCP → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
  • Aauto-paper-improvement-loopAutonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.

All agent skills → · MCP servers