Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Orchestrate the complete post-first-draft polishing pipeline for an academic LaTeX paper by invoking five existing skills in fixed order: (1) paper-polish, (2) paper-self-revise, (3) paper-style, (4) paper-polish again, (5) reference-verify. Trigger when user says "paper pipeline" / "paper-pipeline" / "论文流水线" / "全流程打磨" / "一条龙打磨" / "初稿打磨" / "full polish pipeline" / "run the whole pipeline", or wants the entire post-draft polishing sequence run on a paper folder. Use this skill whenever the user a
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 1054% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 206% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 436% | 0% |
| case-13 | ✗→✓ | ▲ Improved | 82% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 93% | 0% |
This skill runs the full post-first-draft polishing process on an academic paper by invoking five existing skills in a fixed order. It is an orchestrator: it does not duplicate any sub-skill's logic. Each stage is executed by invoking the corresponding skill with the Skill tool and following that skill's own workflow to full completion before moving on.
The pipeline (fixed order — never reorder or skip without explicit user request):
| Stage | Skill | Purpose in the pipeline | |-------|-------|------------------------| | 1 | paper-polish | Clean mechanical, consistency, and citation errors so the self-review can focus on substance | | 2 | paper-self-revise | Deep internal review and content revision on a clean draft | | 3 | paper-style | Restructure title + sections to the target journal, after content has stabilized | | 4 | paper-polish | Second pass: catch issues introduced by Stages 2–3 (cross-references, merge seams, new prose) | | 5 | reference-verify | Final reference audit, once the citation set is settled by all prior edits |
The order matters: polishing before reviewing keeps the review substantive; restructuring after content revision avoids churn; the second polish exists specifically because Stages 2–3 modify text and structure; reference verification runs last because earlier verification would be partially invalidated by later edits.
Input: A project folder containing main.tex (plus tables/figures, ref.bib). Output: The fully polished main.tex + ref.bib, per-stage backups, a ref_verify_report.xlsx, and a final pipeline report.
$ARGUMENTS or ask. Verify main.tex exists with Glob.*冲突副本* and *conflicted copy*. If found, stop and ask the user to resolve which version is canonical before anything else. Re-run this check between every stage (concurrent Overleaf editing can silently revert edits, and a 5-stage pipeline is a long exposure window).pipeline_state.json exists in the folder and has incomplete stages, show its status and ask: resume from the first incomplete stage, or start over from Stage 1? If resuming, skip directly to that stage.$ARGUMENTS, use it. Otherwise use AskUserQuestion with common options (JFE / JF / RFS / Management Science) plus "Other" for free-form input.pipeline_backups/ subfolder and copy main.tex → pipeline_backups/main_stage0.tex and ref.bib → pipeline_backups/ref_stage0.bib. After each completed stage, snapshot main.tex as main_after_stage<N>.tex. These snapshots are the rollback path if a later stage goes wrong.pipeline_state.json in the project folder:json{ "folder": "<path>", "target_journal": "<journal>", "mode": "stage-confirm", "started": "<date via Bash>", "stages": { "1_paper_polish": "pending", "2_paper_self_revise": "pending", "3_paper_style": "pending", "4_paper_polish_2nd": "pending", "5_reference_verify": "pending" } }
Update the relevant stage to "in_progress" when it starts and "done" when it completes. This file is what makes the pipeline resumable after an interrupted session.
For every stage, follow this exact sequence:
════════════════════════════════════════
Stage N/5: <skill-name> — <one-line purpose>
════════════════════════════════════════in_progress in pipeline_state.json.skill: paper-polish, args: <folder path>). Then follow the loaded skill's instructions to full completion — all of its checks/comments/phases, including its own completion summary. Never paraphrase or shortcut a sub-skill's workflow; the whole point of the pipeline is that each stage runs exactly as it would standalone.apply: auto (reference-verify). Still display each change block as the sub-skill specifies, so the user can scroll back and audit; just don't wait for input.main.tex to pipeline_backups/, mark the stage "done", re-run the Dropbox conflict check, and record a 3–5 line stage summary (counts of changes applied/skipped, sections touched, anything flagged).Stage 1 — paper-polish (first pass): Run all 19 checks as the skill specifies. Pass the project folder path as args.
Stage 2 — paper-self-revise: The skill's Phase 0 asks whether a review report already exists. In the pipeline context, prefer a fresh review: if a review.pdf/review.md from an earlier round is present, ask the user whether to reuse it or regenerate (stale comments may already be addressed); in 全自动 mode, regenerate without asking. The generated review excludes anything requiring new empirical work, which matches the pipeline's text-only scope.
Stage 3 — paper-style: Pass both the folder path and the target journal collected in Phase 0 as args, so the skill's Phase 0 journal question is already answered. In 全自动 mode the skill's fast path picks the title itself; when in doubt there, prefer keeping the current title (case-adjusted) — the title is the most subjective change in the whole pipeline and the easiest to get wrong silently.
Stage 4 — paper-polish (second pass): Run all 19 checks again in full. Expect the yield to concentrate in: hardcoded section references broken by Stage 3 renumbering, merge-seam transitions, abbreviations re-defined or orphaned by moved text, text–table consistency in paragraphs Stage 2 rewrote, and em-dashes introduced by new prose. A second full pass is deliberate — do not skip checks just because Stage 1 ran them.
Stage 5 — reference-verify: Run on the project directory (Excel output, default settings). Map the pipeline mode onto APPLY_FIXES: 全程交互 → interactive; 阶段确认/全自动 → auto. The skill makes its own timestamped backups before editing and writes ref_verify_changes.md.
After Stage 5, mark all stages done in pipeline_state.json and present:
# Paper Pipeline 完成报告
论文: <title> 目标期刊: <journal> 模式: <mode>
| Stage | Skill | 应用 | 跳过 | 要点 |
|-------|-------|------|------|------|
| 1 | paper-polish | 12 | 3 | 修正 5 处文表不一致 |
| 2 | paper-self-revise | 9 | 1 | 审稿报告 14 条意见,强化引言张力 |
| 3 | paper-style | — | — | 10→8 节,标题改为 sentence case |
| 4 | paper-polish (2nd) | 6 | 0 | 修复 3 处硬编码 Section 引用 |
| 5 | reference-verify | 4 | 1 | 50 条引用,2 条元数据修正,报告见 xlsx |
备份: pipeline_backups/ (main_stage0 … main_after_stage5)
报告文件: review.pdf · ref_verify_report.xlsx · ref_verify_changes.md
遗留事项: <anything any stage flagged but did not fix, e.g. abstract over word limit>The 遗留事项 list matters: sub-skills (especially paper-style Phase 5 and reference-verify) flag out-of-scope issues they deliberately don't fix — collect them all in one place so nothing silently evaporates.
"skipped" in the state file.in_progress for that stage, summarize what was applied so far, and remind the user the pipeline can resume later by re-invoking paper-pipeline on the same folder.---) in any newly written prose, per house rules.Other measured skills in the registry, with their headline benchmark lift.