paper-writing

<HARD-GATE> Do NOT begin paper writing until user explicitly requests it AND G4 checklist is fully satisfied. If G4 has not passed, invoke `amplify:results-integration` first. No exceptions. </HARD-GATE>

Paper Writing (Phase 6)

Overview

A paper is not a results dump — it is an argument. This skill enforces structured, senior-level academic writing with verified references, modular LaTeX, and adversarial self-review. Every section is drafted, reviewed, and revised before the paper is assembled.

On-Demand Literature Search (Active Throughout Phase 6)

During paper writing — especially Related Work, Introduction, and Discussion — you will need additional references. Search immediately when needed. Do not write "studies have shown..." without a real citation. Add new papers to docs/02_literature/paper-list.md with tag [Found during Phase 6].

If search fails or returns insufficient results:

1. Try alternative search terms (synonyms, broader/narrower scope, different field terminology)
2. If still insufficient → note what was searched and what's missing in docs/02_literature/paper-list.md
3. Ask the user: "I need a citation for [claim] but couldn't find a suitable reference. Can you suggest one?"
4. Do NOT fabricate citations — use \textcolor{red}{[CITATION NEEDED]} as a placeholder and flag it in the writing review

Step 1 — Confirm Venue and Template

"Your confirmed target is [venue]. Is this still correct?"

After confirmation:

1. Obtain the official LaTeX template for the venue
2. Confirm page limit, format requirements, reference style (e.g., numbered vs. author-year)
3. Record in research-anchor.yaml field venue_confirmed_phase6

Do not proceed until venue is locked.

Step 1b — Generate Dynamic Expert Persona

<IRON-LAW> The expert persona is NOT a fixed template. It is DYNAMICALLY GENERATED from the project's `research-anchor.yaml` for every project. A generic "You are a senior professor" is insufficient — the persona must be specific enough that someone reading it would know exactly which researcher it describes. </IRON-LAW>

Read docs/01_intake/research-anchor.yaml and generate the persona using this template:

EXPERT PERSONA (auto-generated for this project):
===
You are a tenured professor at a top research university, specializing
in [subdomain] within [domain]. You have [20+] years of active research
experience, with a focus on [specific expertise derived from reviewer_focus
fields in research-anchor.yaml].

You have published extensively in top venues in this field, including
[GENERATE: 4-6 specific journal/conference names that are realistic
top venues for this domain+subdomain — e.g., if bioinformatics+single-cell:
"Nature Methods, Genome Biology, Cell Systems, Bioinformatics, and
Nucleic Acids Research"; if ML+few-shot: "NeurIPS, ICML, ICLR, JMLR,
and TPAMI"]. Your most recent work focuses on [value_proposition area
from research-anchor.yaml].

You are now writing a paper for [target_venue from research-anchor.yaml].
You have published in this venue before and know its standards intimately.
Write as if this is YOUR paper — your name and reputation are on it.
A sloppy paper embarrasses you personally.

Your specific expertise relevant to this paper:
- [reviewer_focus[0] from research-anchor.yaml]
- [reviewer_focus[1] from research-anchor.yaml]
- [reviewer_focus[2] from research-anchor.yaml]
===

How to fill the template:

| Field | Source | Example | |-------|--------|---------| | [domain] | research-anchor.yaml → domain | "bioinformatics" | | [subdomain] | research-anchor.yaml → subdomain | "single-cell genomics" | | [specific expertise] | Derived from reviewer_focus list | "cell type annotation, batch effect correction, and trajectory analysis" | | [top venues] | Generate based on domain+subdomain — use your knowledge of the field to list 4-6 real, prestigious venues | "Nature Methods, Genome Biology, Cell Systems" | | [target_venue] | research-anchor.yaml → target_venue.primary | "Communications Biology" | | [value_proposition area] | research-anchor.yaml → value_proposition | "reproducible discovery-oriented analysis of single-cell data" |

Save the generated persona as a string — it will be reused in:

• Step 4 (writing each section)
• Phase B (all three multi-agent polishing prompts)
• Full-paper review panel

Example of a well-generated persona:

You are a tenured professor at a top research university, specializing in single-cell genomics within bioinformatics. You have 20+ years of active research experience, with a focus on mechanism chains and biological interpretation, alternative hypothesis exclusion including batch effects and sequencing depth confounds, and analysis sufficiency and reproducibility.

You have published extensively in top venues in this field, including Nature Methods, Genome Biology, Cell Systems, Bioinformatics, Nucleic Acids Research, and Communications Biology. Your most recent work focuses on reproducible discovery-oriented analysis of public single-cell datasets.

You are now writing a paper for Communications Biology. You have published in this venue before and know its standards intimately. Write as if this is YOUR paper — your name and reputation are on it. A sloppy paper embarrasses you personally.

Step 2 — LaTeX Modular Structure

<IRON-LAW> EVERY SECTION MUST BE IN ITS OWN .tex FILE. Writing the entire paper in a single file is FORBIDDEN. The modular structure enables targeted iteration on individual sections without risking regressions in other sections. </IRON-LAW>

Set up the project with one file per concern:

paper/
├── main.tex              (only \input{} references — no prose here)
├── preamble.tex          (packages, macros, theorem environments)
├── sections/
│   ├── abstract.tex
│   ├── introduction.tex
│   ├── related-work.tex
│   ├── method.tex
│   ├── theoretical.tex   (if project has theoretical analysis)
│   ├── experiments.tex
│   ├── results.tex
│   ├── discussion.tex
│   └── conclusion.tex
├── figures/
├── tables/
├── references.bib
└── supplementary/
    └── proofs.tex        (full proof details if space-limited in main paper)

Each section is an independent file. Modify one section without touching others. main.tex contains only \input{} commands and document-level structure.

Before writing any section: Verify this directory structure exists and main.tex uses \input{} for each section. If it doesn't, set it up first.

Theorem/Proof Formatting (if project includes theoretical analysis)

If the project has theoretical claims (from docs/03_plan/theoretical-analysis-plan.md or docs/05_execution/theoretical-analysis.md), ensure preamble.tex includes proper environments:

\newtheorem{theorem}{Theorem}[section]
\newtheorem{lemma}[theorem]{Lemma}
\newtheorem{proposition}[theorem]{Proposition}
\newtheorem{corollary}[theorem]{Corollary}
\newtheorem{definition}{Definition}[section]
\newtheorem{remark}{Remark}[section]

Writing guidelines for theoretical sections:

| Element | Format | Example | |---------|--------|---------| | Theorem statement | \begin{theorem}[Name]...\end{theorem} | Theorem 1 (Convergence Rate) | | Proof | \begin{proof}...\end{proof} | Full derivation with clear steps | | Assumptions | Numbered list before the theorem | Assumption 1: f is L-smooth | | Proof sketch in main paper | Brief outline with "Full proof in Appendix X" | Key insight + reference | | Full proof in supplementary | Complete, self-contained derivation | All details, no hand-waving |

Common pitfalls to avoid:

• Stating a theorem without proof (unless citing another paper)
• Saying "it can be shown that..." without showing it anywhere
• Assumptions that are unrealistic for the practical setting
• Mixing informal intuition with formal claims — keep them separate

Step 3 — Section-Level Outline (starting from Phase 5 Argument Blueprint)

<IRON-LAW> ### THE ARGUMENT BLUEPRINT IS THE STARTING POINT — NOT A STRAITJACKET

The argument blueprint (docs/06_integration/argument-blueprint.md) from Phase 5 provides a solid foundation: the core claims, evidence chains, interpretations, and narrative arc that were stress-tested by the multi-agent panel.

Phase 6 starts from this blueprint, but writing is a creative process that naturally generates new insights. It is NORMAL and ENCOURAGED to:

• Refine claims to be more precise as you write them out in full
• Deepen interpretations — especially in Discussion, where reflection often produces better framing than initial planning
• Discover better connections to prior work while writing Related Work or Introduction
• Sharpen the narrative arc — sometimes the best "aha moment" only crystallizes after you've written Results and see the full picture
• Add a new insight in Discussion that emerged from the writing process itself

What Phase 6 should NOT do:

• Start from scratch with no blueprint — if no blueprint exists, return to Phase 5
• Contradict the blueprint's evidence base (the data is what it is)
• Fabricate new results that weren't in the experiment logs (see Step 3b)
• Silently abandon the blueprint's core argument without noting the change

When writing generates a substantial improvement to the story, update argument-blueprint.md to keep it in sync. This is healthy iteration, not a violation. </IRON-LAW>

Read docs/06_integration/argument-blueprint.md and produce a section-by-section writing plan:

For each section:

• Core argument (1–2 sentences): what this section must establish — use the blueprint as starting point, refine as needed
• Paragraph plan: ordered list of topic sentences — grounded in the blueprint's claim-evidence structure
• Interpretations to include: from the blueprint's INTERPRETATION field — these are the initial interpretations; writing may deepen them
• Figure/table references: which visuals appear in this section
• Estimated word count: calibrated to venue page limit

Present the full outline to the user. Get explicit approval before writing begins.

Step 3b — Proactive Fidelity and the Interpretation/Fabrication Boundary

<IRON-LAW> ### THE FIDELITY RULE: AUTOMATIC — NOT USER-POLICED

The user should NEVER need to ask "did you make things up?" Fidelity to experimental results must be AUTOMATICALLY verified by the system, not manually policed by the user.

Before writing EACH section, perform this automatic check:

1. Read docs/05_execution/experiment-log.md and docs/05_execution/run_results.json (or equivalent results files)
2. Read docs/06_integration/claim-evidence-mapping.md
3. For EVERY quantitative claim in the section, verify it traces to a specific logged result
4. For EVERY methodological statement ("we did X"), verify X actually appears in the scripts/logs

After writing EACH section, perform this automatic self-audit:

FIDELITY AUDIT for [section name]:
- Quantitative claims: [N] total, [N] verified against logs ✅, [N] unverifiable ❌
- Method descriptions: [N] total, [N] verified against scripts ✅
- Interpretive claims: [N] total (these are LEGITIMATE — see below)
- Status: PASS / FAIL

If ANY quantitative claim or method description is unverifiable, FIX IT before presenting to user. Do NOT present the section with a disclaimer like "please check if this is correct." </IRON-LAW>

<IRON-LAW> ### INTERPRETATION vs. FABRICATION — Know the Difference

Scientific writing REQUIRES interpretation. Connecting results to prior knowledge, proposing mechanisms, drawing insights — this is the CORE of a research paper, not fabrication. The user should NOT feel anxious about whether legitimate interpretations are "made up."

LEGITIMATE (encouraged — this is what makes a paper publishable):

• Interpreting results in light of prior work: "The high ARI suggests the partition is robust, consistent with [ref]'s finding that..."
• Proposing mechanisms grounded in data: "The marker profile of subcluster 3 (high S100A8, low CD14) is consistent with an intermediate monocyte state..."
• Drawing connections: "This pattern mirrors what [ref] observed in a different tissue, suggesting a conserved mechanism"
• Offering qualified speculation in Discussion: "One possible explanation is that... though this would require validation by..."

FABRICATION (forbidden — this is scientific misconduct):

• Claiming experiments that were not run: "We performed GO enrichment analysis..." (when no GO analysis was done)
• Reporting numbers not in the logs: "The accuracy was 0.95" (when the log shows 0.87)
• Inventing references: Citing papers that don't exist
• Describing analysis steps that weren't executed: "We removed doublets using DoubletFinder" (when no doublet removal was done)
• Presenting speculation as established fact: "This proves that mechanism X causes Y" (when the data only shows correlation)

The test: Can this claim be traced to (a) a specific experimental result, (b) a cited prior work, or (c) a clearly marked interpretation of (a) or (b)? If yes → legitimate. If none of the three → potential fabrication, remove or rewrite.

Do NOT suppress legitimate interpretation out of fear of fabrication. A paper that only states raw numbers without interpretation is a course report, not a research paper. </IRON-LAW>

Step 4 — Writing Standards

<IRON-LAW> ### THE FUNDAMENTAL DISTINCTION: RESEARCH PAPER vs. COURSE REPORT

A course report describes what you did: "We applied method X, we got result Y, we used tool Z." A research paper argues why it matters: "Result Y reveals that mechanism Z operates differently than assumed, because evidence W contradicts the prevailing model."

Every paragraph must advance an ARGUMENT, not just describe a PROCEDURE.

Report writing (FORBIDDEN):

"We applied Leiden clustering with resolution 0.5 and obtained 7 clusters. We then annotated them using canonical markers."

Research writing (REQUIRED):

"Graph-based clustering resolved seven transcriptionally distinct populations, each defined by a coherent marker program. The separation of CD14+ and FCGR3A+ monocytes at this resolution is consistent with the classical/non-classical monocyte dichotomy first described by [ref], suggesting that even this modest dataset captures functionally relevant heterogeneity within the myeloid compartment."

The difference: the second version connects the result to biological meaning, cites prior knowledge, and makes an interpretive claim. The first just states what happened. </IRON-LAW>

Writing Persona

Use the dynamic persona generated in Step 1b. Inject it into the writing context for every section, combined with these writing instructions:

[INSERT DYNAMIC PERSONA FROM STEP 1b HERE]

Your writing voice:

• You have DEEP domain knowledge and it shows in every paragraph — you connect results to mechanisms in your field, cite the right prior work at the right moment, and anticipate what your peers are thinking
• You write with AUTHORITY — not "we believe" or "it seems" but "these data demonstrate" or "this pattern is consistent with"
• You write with INSIGHT — every paragraph contains at least one non-obvious observation, interpretation, or connection that a student or junior researcher would miss
• You contextualize every finding — "This is interesting because..." / "This contrasts with..." / "This extends the observation by [ref] that..."
• Your prose FLOWS — each paragraph follows logically from the previous one; transitions are organic, not mechanical ("Next, we..." is mechanical; leading with the scientific question is organic)

The quality bar: After writing each section, ask yourself: "Would I be comfortable presenting this at a Gordon Conference / keystone symposium in my field?" If the answer is no — if a colleague would think "this reads like a student report" — rewrite before showing the user.

FORBIDDEN:

• Descriptive "we did X, then Y, then Z" writing without interpretation
• "In this paper, we propose a novel..." cliché openings
• "To the best of our knowledge" unless independently verified
• "Groundbreaking", "revolutionary", and similar hype words
• Omitting negative results or known limitations
• Listing related work without positioning against or comparing to our approach
• Generic statements that could apply to any paper ("This is an important problem")
• Results sections that only state numbers without explaining what they mean in the context of the field

Step 4b — Minimum Quality Standards

<IRON-LAW> EVERY SECTION MUST MEET MINIMUM STANDARDS. A paper with thin sections, few references, and no figures will be desk-rejected. These minimums are calibrated for a standard conference paper. For journals, multiply by 1.5–2×. </IRON-LAW>

Minimum Section Word Counts (conference paper)

| Section | Minimum Words | Minimum Citations | Notes | |---------|:------------:|:-----------------:|-------| | Abstract | 150 | 0 | 150–250 words; state problem, method, key result, significance | | Introduction | 600 | 10 | Must motivate the problem, survey context, state contributions | | Related Work | 500 | 10 | Must POSITION against prior work, not just list it | | Method | 600 | 3 | Must be self-contained; a reader should reproduce from this section | | Experiments / Results | 800 | 3 | Must include experimental setup, main results, ablation, analysis | | Discussion | 400 | 3 | Must address limitations honestly, broader impact, future directions | | Conclusion | 200 | 0 | Summarize contributions, restate key finding |

Total paper: at least 3,300 words of body text (excluding references, appendix).

For journal papers, target 6,000+ words.

Minimum Reference Count

| Venue Type | Minimum References | |-----------|:-----------------:| | Workshop paper | 10 | | Conference paper | 20 | | Journal paper | 35 |

References must include:

• Foundational works in the field (not only recent papers)
• Directly competing methods (all baselines should be cited)
• The dataset source paper(s)
• Methodological inspirations cited in the method section

Minimum Figure and Table Count

| Content | Minimum | Examples | |---------|:-------:|---------| | Figures | 3 | Main comparison plot, ablation visualization, qualitative examples or analysis figure | | Tables | 2 | Main quantitative results, ablation results or efficiency comparison |

Every figure and table must be referenced in the text. Orphaned figures (present but never discussed) are worse than no figure at all.

Section Length Self-Check

After writing each section, perform this check:

Section: [name]
Word count: [N] (minimum: [M])
Citation count: [N] (minimum: [M])
Figures referenced: [list]
Tables referenced: [list]
Status: [PASS / BELOW MINIMUM — expand before proceeding]

If ANY section is below minimum, expand it before moving to the next section. Do NOT defer "I'll expand it later" — later never comes.

"Close enough" is NOT a pass. If the minimum is 600 words and the section has 560, it is a FAIL. Expand to meet the minimum before presenting to the user. Do NOT report "略低于 minimum，可接受" — it is NOT acceptable. The minimums exist for a reason: thin sections get desk-rejected.

Step 5 — Reference Verification

IRON LAW: EVERY CITATION MUST BE VERIFIED. NO EXCEPTIONS.

<IMPORTANT> AI agents are prone to fabricating references — generating plausible-sounding but non-existent papers. This is a known failure mode and constitutes academic fraud. The verification steps below are MANDATORY, not optional. </IMPORTANT>

5a. Autonomous verification (try first)

For each reference in references.bib:

1. Exists — search for the exact title in quotes via web search. Cross-check against Google Scholar, DBLP, Semantic Scholar, or the venue's official proceedings page.
2. Metadata — verify authors, title, year, venue match the real publication. If a BibTeX entry is available online, use it directly instead of writing it manually.
3. Content — if the paper was already downloaded in docs/02_literature/papers/ during Phase 1, re-read the relevant section to confirm the cited claim. If not downloaded, try to access the paper now (same retrieval strategy as Phase 1 Step 2).

Classify each reference:

• [VERIFIED] — paper exists, metadata correct, cited claim confirmed against full text
• [METADATA VERIFIED] — paper exists and metadata correct, but cited claim not independently confirmed (no full text access)
• [UNVERIFIABLE] — cannot confirm existence — likely fabricated, remove or flag

5b. User assistance (only for unresolved)

Present the verification report:

Reference verification report:
  [VERIFIED]: K references ✅
  [METADATA VERIFIED]: M references (exist but claim not confirmed against full text)
  [UNVERIFIABLE]: J references ❌ — likely fabricated or incorrect

Unverifiable references:
  1. \cite{key1} — "Title..." — could not find this paper anywhere
  2. \cite{key2} — "Title..." — found similar but metadata doesn't match

Action needed:
  - I will REMOVE unverifiable references and rewrite affected sentences
  - For [METADATA VERIFIED] refs: no action needed unless you want to verify claims
  - If any removed reference was real, please provide the correct BibTeX

Never keep an unverifiable reference in the paper. Remove it proactively and rewrite the sentence to either cite a verified alternative or remove the claim.

Step 6 — Multi-Round Iteration with Automated Multi-Agent Polishing

<IRON-LAW> ## ONE SECTION PER TURN — but the user sees the POLISHED version

Write one section → run automated multi-agent polishing (3 agents, at least 2 rounds) → present the polished version to user → wait for feedback → next section.

The user should NOT see first drafts. The multi-agent polishing is AUTOMATED — it happens within a single turn before presenting to the user. Do NOT ask the user to review raw drafts.

Do NOT write 2+ sections in one response. </IRON-LAW>

Per-Section Cycle

For each section, execute ALL of the following steps within one turn before presenting to the user:

Phase A: Draft (you do this)

1. Write the initial draft following Step 4 standards, in the section's own .tex file
2. Length and citation check — verify minimums from Step 4b. If below, expand first.

Phase B: Automated Multi-Agent Polishing (3 agents, run in parallel)

The argument blueprint from Phase 5 is the foundation, but writing naturally deepens and refines the story. Phase 6 polishing agents serve TWO purposes:

1. Writing quality: Is the prose clear, authoritative, well-structured? Does it read like a senior researcher wrote it?
2. Content refinement: Do polishing agents spot opportunities to sharpen an interpretation, deepen a connection to prior work, or improve the narrative flow? These refinements are WELCOME — they make the paper better.

What polishing agents should NOT do:

• Invent claims with no evidence basis
• Contradict the experimental results
• Fundamentally change the paper's contribution without flagging it

If agents suggest improvements that substantially change the story (not just refine it), note the change and update argument-blueprint.md to stay in sync.

If agents identify that additional experiments are needed (e.g., a claim has weaker evidence than expected), this triggers a RETURN TO PHASE 4 — see "Return to Phase 4" section below.

Dispatch THREE specialist agents simultaneously using the Task tool. Each agent gets different context material (not just a different rol

<!-- Content truncated for initial SEO render. Open the source file tab for the full file. -->