General Principles
Organize the whole paper around one question:How to make reviewers believe this paper is worth publishing. Every time you write a paragraph, ask yourself "Will reviewers believe it when they read this, and what will they ask?"
Research before writing: Every claim must have a verifiable source before it is written; any sentence without source support must be marked [MATERIAL GAP], never fill in from thin air (anti-leakage protocol).brief-driven: A mediocre writer + a good brief beats a good writer with no direction—before writing each section, first state clearly "what is to be argued/which evidence is used/which paper is benchmarked against."
Operating Modes (choose a tier first, don't run the full workflow every time)
full(full draft) / outline-only(outline + argument map only) / abstract-only(abstract only) / section-redraft(rewrite a certain section) / self-review(self-check only). For the trigger/input/steps/output/integrity-gate tier of each mode, see references/operational_modes.md。
Asset Navigation
- Structure Templates:
templates/Six types of skeletons—01_imrad.md(IMRaD empirical) /02_review_survey.md(review/systematic review) /03_theory.md(theoretical methods) /04_case_study.md(case) /05_policy_brief.md(policy brief) /06_conference.md(conference). Each includes section order + word limit per section + [figure slot/table slot] + required statement slots. - End-to-end Example:
examples/worked_example.md—a real "before/after" comparison of brief→configuration→contribution list→outline→argument map→Introduction draft (before = stepping all over the hallucination red line, after = compliant and explicitly marked[MATERIAL GAP]/[RESULT GAP])。 - Self-check Checklist:
references/self_review_checklist.md—8 dimensions of quality + 7 types of failure modes, checkable, with two columns for each item: "what to look at/what triggers rewriting." - Integrity Gate:
references/integrity_gate.md—claim sampling quota (draft ≥30%, final draft 100%) + citation verification actions (curl DOI/Crossref/arXiv/OpenAlex, endpoints have been actually tested and HTTP codes recorded) + Chinese-language literature verification protocol without DOI(three-field comparison method for CNKI/Wanfang/VIP bibliographic records; Chinese-language literature must not skip the integrity gate because it lacks a DOI; during writing this skill is the interceptor, and the verification executor is the Chinese verification fallback checklist of m10 citation, with both sides using consistent standards).Claim ledger implementation: usetemplates/claim_passport.mdto register claims one by one (ID/type ①②③④/source pointer/verification status verified·pending·GAP/HTTP code); this is the load-bearing artifact of the integrity gate; you can rundraft_lint.py --claimsto extract candidate factual sentences for seeding. - reporting guideline mapping:
references/guideline_map.md—experimental/observational/systematic review/diagnostic/prognostic/animal/case/qualitative → CONSORT/STROBE/PRISMA/STARD/TRIPOD/ARRIVE/CARE/SRQR. - Required Statements:
references/mandatory_inclusions.md—Data Availability/Ethics/CRediT/COI/Funding + AI usage statement templates by venue. - Machine Checker:
scripts/draft_lint.py—check for residual GAPs, missing statements, SOTA sentences without significance, and extract citations pending verification.Rewritten to reduce false positives: SOTA wording and significance are determined bysame-sentence/adjacent-sentence windowco-occurrence judgment (not strictly same-line),Skip ``` code fences, required statements are checked byline-start markdown headings(not full-text substrings);--claimsextract candidate fact sentences to seed the claim ledger,--jsonproduce machine-readable results for the orchestrator to judge gate passage.python scripts/draft_lint.py <draft.md> [--final] [--claims] [--json]; self-test--selftest. Human judgment takes priority, machine checks as fallback.
Before writing
Confirm the innovation points (m03/m04), results and highlights (m06), and target venue style (db01/db02). For the writing order, refer to a mature pipeline (ARS):
- Paper Configuration: decide the structure type (IMRaD / review / theoretical analysis / case study / policy brief / conference paper) and target venue.
- Contribution list (about 3 items): serves as the pillar of the whole paper; every section must serve it.
- Outline + Argument Map: draw out the "claim → evidence → rebuttal" chain before starting to write.
- Extract from db02 thestructural conventionsof this type of paper (section order, word/page limits, figure and table norms), without copying the content. For venue templates, be sure to use theversion from the target year(NeurIPS/ACL/IEEE templates change year by year; note the double-blind anonymity rules).
- Layered use: structural conventions (title_pattern/section order/five-paragraph abstract) come from the methodology layer (patterns_library + structural breakdown of each card) and can be used directly as domain-neutral; but when takingcredibility endorsements, filter sample cards by the target venue direction using
domain_scope=— for non-cs.* directions (statistics/medicine/agriculture/social sciences), competition rankings/SOTA/open-source social proof are prohibited; use general endorsements instead (theoretical guarantees/third-party benchmarks/real deployments), see Table D at the end of samples_real. - If any citation count from a card is used as evidence, it must be refreshed in real time via
databases/db02-paper-writing/scripts/paper_signal.py --doi <DOI>; do not trust local snapshots. When reading external PDF/DOCX/PPTX materials, you can use MarkItDown to convert them to Markdown before feeding them to the model (markitdown paper.pdf -o paper.md)。
- Layered use: structural conventions (title_pattern/section order/five-paragraph abstract) come from the methodology layer (patterns_library + structural breakdown of each card) and can be used directly as domain-neutral; but when takingcredibility endorsements, filter sample cards by the target venue direction using
Module-by-module key points
- Title: accurate + informative + reflects innovation, avoid exaggeration.
- Abstract: background → problem → method → key results (with numbers) → significance, 150–250 words.
- Introduction: problem → gap → this paper's approach → contribution list → result preview. The gap must be supported by literature (each gap backed by 3–5 citations).
- Related work: organize by taxonomy, and at the end of each category point out "the difference from this paper"; do not write a running account. This is the deciding factor in peer review, so invest generously in review synthesis.Actionable micro-workflow:① Choose the taxonomy axis— choose 1 main axis from one of "method family/problem setting/data modality/core pain point addressed" and divide into 2–4 categories (do not write a chronological running account); ② For each category write the delta sentenceskeleton: "
<这类工作>achieved<X>, but<未解决的 Y>; this paper fills in<机制>through<Y>" — it must land on a substantive difference (not "we also did X"); ③ Lock in strong baselines: list, within each category, thestrongest/newest/most similarseminal works (not the easiest weak baselines to beat); experimental comparisons must include them, otherwise reviewers will ask "why not compare with X"; ④ attach claim-ledger category-① verification metadata to every citation. Better to cite fewer but accurately than to pile them up (piling up easily induces hallucinations, violating M2). - Method: from intuition to formalization, with clear formula definitions, accompanied by a framework diagram (m09), reproducible.
- Experiments: first explain the setup (data/baselines/metrics/implementation details), then main results, ablations, sensitivity, generalization, robustness, corresponding to the m05 design. Use "data-driven placeholders" in the results section: explicitly write out key numbers + significance (e.g., p<0.001) + comparison with literature baselines.
- Results analysis: explain why, cite insights from m06, acknowledge unfavorable results.
- Discussion: significance, applicable boundaries, dialogue with existing work.
- Conclusion: echo the contributions, do not introduce new content.
- Limitations + future work: honest, demonstrating reviewer-friendliness.
When a paper "falls a bit short": tell the story honestly and well
Not every paper has top-conference-level innovation. When m04 rates it as merely "incremental", the core overlaps with prior work, or the main method fails,telling a good story ≠ exaggeration or fabrication—it is, under the premise of strictly upholding the integrity gate, presenting the true contributions in the most persuasive framework. This is a writing skill, not a fig leaf for academic misconduct. Establish two iron rules first:(1) Never misreport ② incremental as ① innovative(m04 has already checked for core overlap; misreporting will be caught);(2) Never hide failures/negative results. On top of that:
- Reposition the contribution rather than exaggerate it. If the core has been done by predecessors → do not pretend to be the first; instead play the "breadth/rigor/unified comparison/reproducibility" card: explicitly acknowledge prior work (set up a dedicated "Closest prior work" paragraph, explaining the delta sentence by sentence), and shift the selling point to "the first systematic comparison of X/Y/Z under a unified protocol" or "the first solid evidence with multiple seeds + paired statistics + effect sizes". What reviewers hate is "pretending not to see prior work", not "incremental but honest".
- Turn negative results/failures into selling points. If the main method does not work, but "we tried a seemingly obvious shortcut, proved it does not work, and explained why" has scientific value in itself—it prevents others from repeating the same mistake and can conversely strengthen the main conclusion (e.g., "there is no data-free shortcut, so data-driven calibration is necessary"). Give negative results their own section, explain the mechanism clearly, and provide a falsifiable explanation.
- Narrow the framing to a defensible scope. If you cannot reach "we solved X", honestly write "we characterized the boundary/cost of X under condition Y". A small but true claim is harder to reject than a large but empty claim. The title, abstract, and contribution list should shrink in sync to a scale the evidence can support.
- Organize with a story arc, but attach evidence to every turn. A good story = tension (an overlooked cost/contradiction) → escalation (how common and severe it is, with numbers) → turn (can it be fixed, and at what cost) → landing point (actionable recommendations). Every link is backed by real experimental numbers, not adjectives.
- Honesty earns trust, trust earns acceptance. Proactively write full limitations, acknowledge unfavorable results, and name prior work stronger than yours—reviewer-friendliness directly affects the score. Once hidden weaknesses are exposed, the credibility of the whole paper drops to zero.
- Choosing the right venue is also part of storytellingIncremental solid work submitted to a workshop / applied track / short paper is more likely to be accepted than forcing a submission to a top conference main track; when submitting to m13 venue-matching, honestly report "this is incremental" so it matches the realistic tier, and don't submit to a venue doomed to rejection just for the sake of appearances.
After finishing each module, immediately self-check one round from the perspectives of m08 (polishing) + m14 (mock review). For the complete checkable list, see
references/self_review_checklist.md(8 dimensions + 7 patterns, each item includes "what triggers rewriting").
Mock Review 8-Dimension Self-Assessment Checklist(ScholarEval dimensions, point out what can be improved item by item; relative self-checking is more reliable than assigning absolute scores): Novelty / significance and impact / methodological rigor / clarity / reproducibility / support from experimental evidence / positioning relative to existing work / honesty about ethics and limitations.
7-Category AI Failure Mode Red-Line Self-Check(derived from the failure mode analysis of The AI Scientist; clear each item one by one while writing the draft):
M1 treating an implementation bug as passing; M2 hallucinated citations (fabricated references); M3 hallucinated experimental results; M4 taking shortcuts; M5 packaging a bug as a "new insight"; M6 methodological fabrication; M7 early frame-lock.
Citation verification: citation key/DOI/arXiv ID are only traceability fields and do not mean the paper actually supports your argument—click through and check anything doubtful. For the verification quota and curl actions, see references/integrity_gate.md。
In the main text, citation placeholders should uniformly use machine-readable citekeys: write it as \cite{authorYearWord}——first author's surname + year + first content word of the title, all lowercase(e.g., \cite{zhang2024deep}), do not use [Zhang 2019] and similar free-text placeholders (when typesetting to m10 they will fail to match .bib keys and report undefined citation). This formula is from the same source as the citekey pinned when m10 citation generates the .bib.
Deliver only after revising. During revision, track scores dimension by dimension, and beware of regressions where "fixing A breaks B".
Outputs
Modular Markdown/LaTeX drafts + contribution list + markers for content to be added ([MATERIAL GAP]/[RESULT GAP]/TODO, such as missing figures or missing experiments). Before submission, go through the declaration checklist of references/mandatory_inclusions.md and the final draft gate of references/integrity_gate.md (100% claim/citation verification). Align terminology with the db09 glossary (a07). It is recommended to put outputs in a timestamped directory for version management.
Artifact names written to disk (CONVENTIONS §6.1, consumed by downstream m08/m09/m10/m12):draft.md(modular drafts, with m08 polishing iterating on the same draft) + claim_passport.md(claim ledger).
Interfaces
Figures and tables go to m09/m11, citations go to m10 (in the main text, \cite{} placeholders use the authorYearWord formula, from the same source as the citekey pinned by m10), typesetting goes to m12, polishing goes to m08, and mock review goes to m14. Before delivery, pass the a08 (light-self-review) self-check gate. Versions go into db09.
For tool research notes (real endpoints/methods/limitations), see references.md。