auto-paper-improvement-loop
Autonomously 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.
By wanshuiyin · 438 installs
npx skills add wanshuiyin/auto-claude-code-research-in-sleep --skill auto-paper-improvement-loop
Source repository · Upstream listing
Auto Paper Improvement Loop: Review → Fix → Recompile
🔒 Do not wrap this skill in /loop , /schedule , or CronCreate . It
already loops internally (review → fix → recompile) with its own round
structure and a deliberate fresh reviewer bias guard each round (no
codex reply ). Re asking it to "improve the paper" on a
wall clock timer produces no new signal — quality changes when the review
changes, not when the clock ticks — and a timed re run that also accepts its
own output to decide when to stop crosses into self acquittal
( acceptance gate.md ). Schedule the external wait that precedes it , not the
improvement loop. See
[ shared references/external cadence.md ](../shared references/external cadence.md).
Autonomously improve the paper at: $ARGUMENTS
Context
This skill is designed to run after Workflow 3 ( /paper plan → /paper figure → /paper write → /paper compile ). It takes a compiled paper and iteratively improves it through external LLM review.
Unlike /auto review loop (which iterates on research — running experiments, collecting data, rewriting narrative), this skill iterates on paper writing quality — fixing theoretical inconsistencies, softening overclaims, adding missing content, and improving presentation.
Constants
MAX ROUNDS = 2 — Two rounds of review→fix→recompile. Empirically, Round 1 catches structural issues (4→6/10), Round 2 catches remaining presentation issues (6→7/10). Diminishing returns beyond 2 rounds for writing only improvements.
REVIEWER MODEL = gpt 6 astra — Model used via Codex MCP for paper review.
REVIEWER BIAS GUARD = true — When true , every review round uses a fresh mcp codex codex thread with no prior review context. Never use mcp codex codex reply for review rounds. Set to false only for deliberate debugging of the legacy behavior. Empirical evidence: running the same paper with codex reply + "since last round we did X" prompts inflated scores from real 3/10 → fake 8/10 across multiple rounds; switching to fresh threads recovered the true 3/10 assessment.
REVIEW LOG = PAPER IMPROVEMENT LOG.md — Cumulative log of all rounds, stored in paper directory.
HUMAN CHECKPOINT = false — When true , pause after each round's review and present score + weaknesses to the user. The user can approve fixes, provide custom modification instructions, skip specific fixes, or stop early. When false (default), runs fully autonomously.
EDIT WHITELIST = null — Optional path to a YAML/JSON whitelist file constraining which paths and operations the fix implementation step may touch. When null (default), all edits proceed unconstrained. When set via — edit whitelist <path (also accepts — edit whitelist <path ), the loop loads the file at startup and consults it before each edit; rejected edits are logged to PAPER IMPROVEMENT LOG.md rather than silently dropped. See "Optional: Edit Whitelist" below.
💡 Override: /auto paper improvement loop "paper/" — human checkpoint: true
Optional: Style reference ( — style ref: <source , opt in)
Lets the user steer structural fixes only during improvement (section reordering hints, paragraph length nudges, figure density adjustments) 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 the loop starts:
Sources accepted: local TeX dir / file, local PDF, arXiv id, http(s) URL. Overleaf URLs/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 only during the fix implementation phase, to nudge structural choices when applying reviewer feedback. Reviewer feedback always takes precedence; style ref is tie breaker for how to apply a fix, not whether to apply it.
Never copy prose, claims, examples, or terminology from anything reachable through the cache when implementing fixes.
Never pass — style ref (or the cache contents) to the GPT 6 Astra reviewer sub agent. The Reviewer Independence Protocol below requires reviewers see only the artifact and the user's prompt — leaking the style ref would contaminate the review with author side context. This is the most critical invariant in this skill.
Optional: Edit Whitelist ( — edit whitelist <path , opt in)
Lets the caller hard constrain which files and operations the fix implementation step (Step 3 / Step 6) is allowed to touch. Default OFF — when the user does not pass — edit whitelist (or the alias — edit whitelist ), the loop applies all reviewer driven edits without restriction, exactly as before.
This is the parameter that upstream pipelines (e.g. /resubmit pipeline Phase 2) use to enforce text only resubmit microedits: no .bib mutations, no .sty / .bst mutations, no edits to prior submission directories, no new \cite{...} , no new theorem environments, no new numerical claims.
Schema
The whitelist file is YAML or JSON. All four sections are optional:
Resolution rules
allowed paths empty AND forbidden paths empty → whitelist is a no op (advisory: the file is loaded and rationale echoed to the log, but no path filtering is applied).
allowed paths empty, forbidden paths non empty → all paths NOT matched by forbidden paths are mutable.
allowed paths non empty, forbidden paths empty → only paths matching allowed paths are mutable.
Both non empty → an edit is allowed iff the target matches allowed paths AND does NOT match forbidden paths . forbidden paths always wins on overlap.
forbidden operations missing or empty → no operation level guard; only path level filtering applies.
Glob semantics
Use bash extglob / Python fnmatch.fnmatch semantics. matches any depth (zero or more directory segments). Patterns are matched against the path relative to the paper directory (e.g. paper/sec/intro.tex matches sec/ .tex when paper directory is paper/ ).
Forbidden operation detectors
For each candidate edit's diff (the new lines being added — deletions are exempt), the loop runs these regex checks and rejects if any forbidden operation matches:
Operation Detector (added lines only)
new cite \\cite[a zA Z] \{[^}]+\} (catches \cite , \citep , \citet , \citeauthor , \citeyear , \citealp , etc.)
new bibitem \\bibitem\{[^}]+\}
new theorem env \\begin\{(theorem lemma proposition corollary)\ ?\}
numerical claim New token matching \b\d+(\.\d+)?%?\b that did NOT appear in the deleted/replaced lines (i.e. genuinely new numbers, not edits to existing ones)
Behavior at loop start (before Round 1 fix implementation)
1. If — edit whitelist <path is present in $ARGUMENTS , set EDIT WHITELIST = <path .
2. Load the file ( yaml.safe load ; if it fails, fall back to json.loads ). On load failure, abort the loop with a clear error — do NOT silently proceed unconstrained.
3. Echo rationale (if present) into PAPER IMPROVEMENT LOG.md under a new "Edit Whitelist" preamble section so the audit trail records why edits were constrained.
Behavior during fix implementation (Steps 3 and 6)
Before applying each proposed edit:
1. Resolve target file path relative to the paper directory.
2. Path check: if allowed paths is non empty, target must match at least one pattern. Then if forbidden paths is non empty, target must NOT match any pattern. If either fails → reject as path violation.
3. Operation check: build the unified diff (or just the set of newly added lines) for the proposed edit. For each entry in forbidden operations , run its detector on the added lines. If any detector matches → reject as operation violation.
4. If all checks pass, apply the edit normally.
5. If rejected, append an entry to PAPER IMPROVEMENT LOG.md under a Rejected by edit whitelist (Round N) heading with this schema:
6. Continue with the remaining edits in the round. Do NOT abort the whole round on a single rejection.
End of round surfacing
At the end of each round (after the recompile, before moving to the next round), if any edits were rejected during that round's fix step:
Print a one line summary to the round's checkpoint output: Edit whitelist rejected N edits this round (M path, K operation). See PAPER IMPROVEMENT LOG.md "Rejected by edit whitelist (Round N)".
If HUMAN CHECKPOINT = true , include the rejection list in the checkpoint shown to the user before they approve next round fixes.
Example invocations
Rationale
Without a whitelist, the loop's reviewer driven fix step is free to add citations, introduce new theorem environments, or tweak numerical claims — all of which are reasonable for first submission polish but forbidden in resubmit / camera ready / rebuttal only modes where the paper structure is frozen by external constraint. Routing those constraints through a first class parameter (rather than relying on the LLM to "remember" not to do them) makes the constraint enforceable, auditable via PAPER IMPROVEMENT LOG.md , and visible to the user at each round's checkpoint.
Inputs
1. Compiled paper — paper/main.pdf + LaTeX source files
2. All section .tex files — concatenated for review prompt
State Persistence (Compact Recovery)
If the context window fills up mid loop, Claude Code auto compacts. To recover, this skill writes PAPER IMPROVEMENT STATE.json after each round:
On startup : if PAPER IMPROVEMENT STATE.json exists with "status": "in progress" AND timestamp is within 24 hours, read it + PAPER IMPROVEMENT LOG.md to recover context, then resume from the next round. Otherwise (file absent, "status": "completed" , or older than 24 hours), start fresh.
After each round : overwrite the state file. On completion : set "status": "completed" .
Reviewer Independence Protocol
The reviewer must be context naive on every round. Prior round summaries, fix lists, and executor explanations are not evidence; they are a source of confirmation bias. If the reviewer is told what changed, scores tend to drift upward even when the manuscript itself has not materially improved.
Rules:
Every round starts with mcp codex codex , not mcp codex codex reply .
Never pass a prior threadId into the next review prompt.
Never include "since last round", "we fixed", "after applying", or any fix summary in the reviewer prompt.
The only acceptable evidence of improvement is the current .tex source and compiled PDF.
If a fix cannot be observed in the files, the reviewer should not be told it happened.
If recovery metadata is needed, store the returned threadId for crash recovery only; do not use it to preserve review context.
Set REVIEWER BIAS GUARD = false only if you explicitly want the legacy, context carrying behavior for debugging.
Workflow
Step 0: Preserve Original
Step 1: Collect Paper Text
Concatenate all section files into a single text block for the review prompt:
Step 2: Round 1 Review
Send the full paper text AND compiled PDF to GPT 6 Astra xhigh:
Save the threadId for Round 2.
Step 2b: Human Checkpoint (if enabled)
Skip if HUMAN CHECKPOINT = false .
Present the review results and wait for user input:
Parse user response same as /auto review loop : approve / custom instructions / skip / stop.
Step 3: Implement Round 1 Fixes
Parse the review and implement fixes by severity:
Priority order:
1. CRITICAL fixes (assumption mismatches, internal contradictions)
2. MAJOR fixes (overclaims, missing content, notation issues)
3. MINOR fixes (if time permits)
Edit whitelist gate (if set): If EDIT WHITELIST is set, before applying each proposed edit, check the target path against allowed paths / forbidden paths and the new l