paper-writing

name paper-writing description Workflow 3: Full paper writing pipeline that goes from a narrative report to a polished, submission-ready PDF. Use when user says "写论文全流程", "write paper pipeline", "从报告到PDF", "paper writing", or wants the complete paper generation workflow. argument-hint [narrative-report-path-or-topic] [— style-ref: <source>] allowed-tools Bash(*), Read, Write, Edit, Grep, Glob, Skill, mcp__codex__codex, mcp__codex__codex-reply Workflow 3: Paper Writing Pipeline Orchestrate a complete paper writing workflow for: $ARGUMENTS Overview This skill chains five sub-skills into a single automated pipeline: /paper-plan → /paper-figure → /paper-write → /paper-compile → /auto-paper-improvement-loop (outline) (plots) (LaTeX) (build PDF) (review & polish ×2) Each phase builds on the previous one's output. The final deliverable is a polished, reviewed paper/ directory with LaTeX source and compiled PDF. In this hybrid pack, the pipeline itself is unchanged, but paper-plan and paper-write use Orchestra-adapted shared references for stronger story framing and prose guidance. Constants VENUE = ICLR — Target venue. Options: ICLR , NeurIPS , ICML , CVPR , ACL , AAAI , ACM , IEEE_JOURNAL (IEEE Transactions / Letters), IEEE_CONF (IEEE conferences). Affects style file, page limit, citation format. MAX_IMPROVEMENT_ROUNDS = 2 — Number of review→fix→recompile rounds in the improvement loop. REVIEWER_MODEL = gpt-6-astra — Model used via Codex MCP for plan review, figure review, writing review, and improvement loop. AUTO_PROCEED = true — Auto-continue between phases. Set false to pause and wait for user approval after each phase. HUMAN_CHECKPOINT = false — When true , the improvement loop (Phase 5) pauses after each round's review to let you see the score and provide custom modification instructions. When false (default), the loop runs fully autonomously. Passed through to /auto-paper-improvement-loop . ILLUSTRATION = figurespec — Architecture/illustration generator for Phase 2b: figurespec (default, deterministic JSON→SVG via /figure-spec , best for architecture/workflow/topology), gemini (AI-generated via /paper-illustration , best for qualitative method illustrations; needs GEMINI_API_KEY ), codex-image2 (AI-generated via /paper-illustration-image2 through the local Codex native image bridge — no external API key, uses your ChatGPT Plus/Pro quota; experimental), mermaid (Mermaid syntax via /mermaid-diagram , free, best for flowcharts), or false (skip Phase 2b, manual only). Override inline: /paper-writing "NARRATIVE_REPORT.md" — venue: NeurIPS, illustration: gemini, human checkpoint: true IEEE example: /paper-writing "NARRATIVE_REPORT.md" — venue: IEEE_JOURNAL Inputs This pipeline accepts one of: NARRATIVE_REPORT.md (best) — structured research narrative with claims, experiments, results, figures Research direction + experiment results — the skill will help draft the narrative first Existing PAPER_PLAN.md — skip Phase 1, start from Phase 1.5 (the contract negotiation still runs; only resuming a genuine pre-1.5 legacy run may skip it, and then Phase 6.0's row 0 records "no contract") The more detailed the input (especially figure descriptions and quantitative results), the better the output. Optional: Style reference ( — style-ref: <source> , opt-in) Lets the user steer structural style (section ordering, theorem density, sentence cadence, figure density, bibliography style) of the generated paper toward a reference paper they admire. Default OFF — when the user does not pass — style-ref , do nothing differently from before. When — style-ref: <source> is in $ARGUMENTS , run the helper FIRST, before Phase 1 (paper-plan): # 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) ;; # share $CACHE/style_profile.md with downstream WRITER phases only 2) echo "warning: style-ref skipped (missing optional dep)" >&2 ;; 3) echo "error: --style-ref source failed; aborting pipeline" >&2 ; exit 1 ;; *) echo "error: helper failed unexpectedly; aborting pipeline" >&2 ; exit 1 ;; esac Then forward — style-ref: <source> only to the writer-side sub-skills: /paper-plan (Phase 1) — outline structure /paper-write (Phase 3) — section-by-section prose /paper-illustration (Phase 2b) — figure structural matching, optional 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 as structural guidance only. Match section-count tendency, theorem density, caption-length distribution, sentence cadence, math display ratio, citation style. Never copy prose, claims, examples, or terminology from anything reachable through the cache. Never pass — style-ref (or the cache contents) to reviewer / auditor sub-skills — Phase 4.5 ( /proof-checker ), Phase 4.7 / 5.5 ( /paper-claim-audit ), Phase 5 ( /auto-paper-improvement-loop reviewer), Phase 5.8 ( /citation-audit ) MUST run on the artifact alone. Cross-model review independence ( ../shared-references/reviewer-independence.md ). Pipeline Phase 0: Assurance Setup Resolve the active assurance level and persist it so Phase 6's external verifier reads the same value. Run once at pipeline start, before Phase 1. Resolution order (first match wins): Explicit — assurance: draft | submission in $ARGUMENTS Derived from — effort: lite / balanced → draft (default, zero change from current behavior ) max / beast → submission Default: draft Action: mkdir -p paper/.aris echo "<resolved-level>" > paper/.aris/assurance.txt # draft or submission What each level does downstream: draft — Existing behavior. Audits run only when their content detector matches (Phase 4.5 / 4.7 / 5.5 / 5.8). Missing artifacts are non-blocking. Silent-skip allowed. submission — The four mandatory audits (proof-checker, paper-claim-audit, citation-audit, kill-argument) are treated as load-bearing gates. Each sub-audit must emit its JSON artifact (PASS / WARN / FAIL / NOT_APPLICABLE / BLOCKED / ERROR) — never silent-skip. Phase 6 runs verify_paper_audits.sh (canonical name; resolved per shared-references/integration-contract.md §2); a non-zero exit blocks the Final Report. Escape hatch: a user wanting the old "beast = depth-only, no audit gate" can pass — effort: beast, assurance: draft explicitly. Legal but discouraged for actual submissions. See shared-references/assurance-contract.md for the full contract. Announce the resolved level in-line before Phase 1: 📋 Assurance: <level> (derived from effort: <effort>) <either "current behavior, no audit gate" OR "mandatory audits gated by verify_paper_audits.sh (resolved per integration-contract §2)"> Phase 1: Paper Plan Invoke /paper-plan to create the structural outline: /paper-plan "$ARGUMENTS" If — style-ref: <source> was passed in $ARGUMENTS and the helper succeeded above, append — style-ref: <source> to the invocation: /paper-plan "<topic> — style-ref: <source>" . (Writer-side phase — forwarding is allowed; reviewer/auditor phases below must not see the style ref.) What this does: Parse NARRATIVE_REPORT.md for claims, evidence, and figure descriptions Build a Claims-Evidence Matrix — every claim maps to evidence, every experiment supports a claim Design section structure (5-8 sections depending on paper type) Plan figure/table placement with data sources Scaffold citation structure GPT-6-Astra reviews the plan for completeness Output: PAPER_PLAN.md with section plan, figure plan, citation scaffolding. Checkpoint: Present the plan summary to the user. 📐 Paper plan complete: - Title: [proposed title] - Sections: [N] ([list]) - Figures: [N] auto-generated + [M] manual - Target: [VENUE], [PAGE_LIMIT] pages Shall I proceed with figure generation? User approves (or AUTO_PROCEED=true) → proceed to Phase 1.5. User requests changes → adjust plan and re-present. Phase 1.5: Negotiated Acceptance Contract (before any writing) The plan says what the paper will contain; the CONTRACT says what "done" means — a checklist of testable assertions, negotiated ADVERSARIALLY before the first section is written, and graded at the end. (The plan is the boundary; the contract is what gets graded.) Executor proposes. From PAPER_PLAN.md + NARRATIVE_REPORT.md , draft PAPER_ACCEPTANCE_CONTRACT.md : 10–20 testable assertions covering — every headline claim has a named evidence source (file/table); every number in the abstract traces to a results file; scope qualifiers the title /abstract must carry; figures that must exist and what each must show; section-level completeness (e.g. "limitations names ≥2 real limitations, not hedges"); venue constraints (page limit, anonymization). Each assertion must be CHECKABLE by reading the final PDF + results files — no vibes ("writing is clear" is not an assertion; "every acronym is defined at first use" is). Fewer than ~10 assertions and the gate rubber-stamps; beyond ~20 the negotiation stalls on trivia. Reviewer pushes back (fresh thread — the negotiation is adversarial): mcp__codex__codex: model: gpt-6-astra config: {"model_reasoning_effort": "xhigh"} prompt: | You are negotiating the acceptance contract for a paper BEFORE it is written. Read these files directly: - Plan: <abs path>/PAPER_PLAN.md - Proposed contract: <abs path>/PAPER_ACCEPTANCE_CONTRACT.md - Evidence inventory: <abs path>/NARRATIVE_REPORT.md (+ results/ paths) Push back on the contract, not the plan: (a) assertions that are untestable or vibes — demand a checkable rewrite; (b) missing assertions — claims in the plan that no assertion covers, numbers with no traceability assertion, foreseeable overclaim risks with no scope assertion; (c) assertions the evidence inventory cannot possibly satisfy — flag now, not after writing. End with exactly one line: CONTRACT_ACCEPTED: yes or CONTRACT_ACCEPTED: no followed by your numbered revision demands if no. === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) === Report anything that is actually wrong here — including a rare-looking case, if this repo actually produces it. Then keep the fix in scope: 1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is welcome; over-defense is not. Assume a cooperating operator on their own machine — a malicious local user is NOT in the threat model. 2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes. Reporting a real defect in hashing code that already exists is fine. 3. NO speculative machinery: do not add feature flags, migration frameworks, compat layers, wrappers, pins, or similar mechanisms unless evidence shows a current repo defect they fix or an explicit existing invariant they must preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels, not evidence. Point to the failing path/artifact or invariant, and check the proposal's factual premises, such as whether a named package version exists. 4. NO corner-case obsession: exotic encodings, symlink races, RTL text and millisecond races are out of scope unless you can show the case arises here. 5. Where a rubric or checklist is genuinely needed, do not over-mechanize judgement. A clear sentence a human reads beats a scored table nobody maintains. Exception: code that runs remote commands, starts a network service, or installs an MCP server runs on the user's machine with their credentials — trust-boundary findings there are in scope and the default is strict. Say plainly when something is correct. Do not manufacture findings. A reply with a missing or malformed CONTRACT_ACCEPTED: line is treated as no ; request a corrected verdict via codex-reply — that correction exchange does not consume a negotiation round. Iterate. On no , revise the contract per the demands and resubmit via mcp__codex__codex-reply (same thread — the negotiation is one conversation). Max 3 rounds. Fallback — never stall the pipeline. If round 3 still ends in no : record the unresolved demands verbatim in a "## Disputed" section of the contract and mark it status: contested . A contested contract is precisely the "insert a human when the CONTRACT is wrong" trigger, so it OVERRIDES AUTO_PROCEED for this one decision: pause and present the dispute for a human tie-break. If no human responds (unattended/overnight run), proceed — but a contested contract caps the outcome: Phase 6.0 gates on the UNDISPUTED assertions and the Final Report must set Submission-ready: no with the dispute reproduced verbatim; the tie-break happens when the human returns. Output: PAPER_ACCEPTANCE_CONTRACT.md ( status: accepted | contested , round count, reviewer thread id). The contract is FROZEN once accepted — Phases 2–5 implement against it; they do not edit it. If writing reveals an assertion is genuinely wrong (not merely inconvenient), that is a contract question: surface it at a checkpoint, don't silently rewrite. Boundary: /paper-claim-audit (Phases 4.7, 5.5) stays zero-context — the contract is a WRITER-side gate and is never passed to the claim auditor (its independence is the point; two different nets). Phase 2: Figure Generation If — style-ref: <source> was passed in $ARGUMENTS and the helper succeeded above, append — style-ref: <source> to every writer-side sub-skill invocation in this pipeline (Phases 1, 2b, 3, 5). Do not append it to reviewer/auditor invocations (Phases 4.5, 4.7, 5.5, 5.8). Invoke /paper-figure to generate data-driven plots and tables: /paper-figure "PAPER_PLAN.md" What this does: Read figure plan from PAPER_PLAN.md Generate matplotlib/seaborn plots from JSON/CSV data Generate LaTeX comparison tables Create figures/latex_includes.tex for easy insertion GPT-6-Astra reviews figure quality and captions Output: figures/ directory with PDFs, generation scripts, and LaTeX snippets. Scope: paper-figure covers data plots and comparison tables. Architecture diagrams, pipeline figures, and method illustrations are handled in Phase 2b below. Phase 2b: Architecture & Illustration Generation Skip this step entirely if illustration: false .