nature-writing

interface:
  display_name: "Nature Writing"
  short_description: "Draft manuscripts and initial-submission materials"
  default_prompt: "Use $nature-writing to draft a Nature-style manuscript section or initial-submission package from these materials."

name: nature-writing
version: 1.5.0
description: >
  Declarative manifest for the static/dynamic split. SKILL.md uses this to
  decide which fragments to load for a drafting, restructuring, or
  initial-submission request.

always_load:
  # Shared layer — common to nature-polishing and nature-writing
  - ../nature-shared/core/reader-workflow.md
  - ../nature-shared/core/paper-type-taxonomy.md
  - ../nature-shared/core/ethics.md
  - ../nature-shared/core/terminology-ledger.md
  # Skill-local core
  - static/core/stance.md
  - static/core/workflow.md
  - static/core/output-format.md

axes:
  task:
    detect: |
      Use submission-package when the user requests first-submission or
      pre-submission materials such as an initial cover letter, title page,
      highlights, author contributions, availability/declaration statements,
      reviewer suggestions, or a complete submission checklist. Use manuscript
      for manuscript sections and argument development. Revision correspondence
      after an editor decision belongs to nature-response, not this skill.
    values:
      manuscript:          static/fragments/task/manuscript.md
      submission-package: static/fragments/task/submission-package.md
    default: manuscript
    multi: false

  paper_type:
    detect: |
      Decide what kind of paper or section is being drafted. Default to research.
      Use the user's stated framing first; fall back to inference from their
      material. Map writing's older taxonomy (mechanism/method/resource/device/
      model/clinical/materials/computational/interdisciplinary) onto these five.
    values:
      research:       static/fragments/paper_type/research.md
      methods:        static/fragments/paper_type/methods.md
      hypothesis:     static/fragments/paper_type/hypothesis.md
      algorithmic:    static/fragments/paper_type/algorithmic.md
      review:         static/fragments/paper_type/review.md
    default: research
    multi: false

  section:
    detect: |
      Identify which section(s) the user wants drafted or rebuilt. The user
      may name one or several. Ask before loading when ambiguous and load
      cost matters. Title and abstract often need to be drafted last but
      planned early.
    values:
      abstract:       static/fragments/section/abstract.md
      intro:          static/fragments/section/intro.md
      related-work:   static/fragments/section/related-work.md
      method:         static/fragments/section/method.md
      experiments:    static/fragments/section/experiments.md
      discussion:     static/fragments/section/discussion.md
      conclusion:     static/fragments/section/conclusion.md
      title:          static/fragments/section/title.md
    multi: true

  language:
    detect: |
      Detect the source language of the user's notes. Use zh-to-en when the
      input is Chinese, mixed Chinese-English, or organized as Chinese lab
      notes. Otherwise use en.
    values:
      en:             static/fragments/language/en.md
      zh-to-en:       static/fragments/language/zh-to-en.md
    default: en
    multi: false

  journal:
    detect: |
      Use nature only for the flagship journal Nature. Use nat-comms for Nature
      Communications. Use nat-mach-intell when the user names Nature Machine
      Intelligence or NMI. If the user says "Nature-family" generically or
      names a different Nature Portfolio subjournal, use nature-family and
      check that journal's current instructions before applying exact numbers.
      Otherwise use generic.
    values:
      nature:         static/fragments/journal/nature.md
      nature-family:  static/fragments/journal/nature-family.md
      nat-comms:      static/fragments/journal/nat-comms.md
      nat-mach-intell: static/fragments/journal/nat-mach-intell.md
      generic:        static/fragments/journal/generic.md
    default: generic
    multi: false

references:
  on_demand:
    - condition: task is manuscript and the user is drafting, restructuring, or compressing Results or full main text; deciding what belongs in main text versus captions or SI; preventing revision accretion; reducing statistical or claim repetition; or building the shortest sufficient evidence chain
      path: ../nature-shared/core/main-text-discipline.md
    - condition: target is flagship Nature, Nature Communications, Nature Machine Intelligence, or another Nature Portfolio title and the user is drafting or restructuring Results, Discussion, or their boundary; testing claim escalation; deciding whether local interpretation or robustness advances the claim; or separating necessary recap from redundant re-demonstration
      path: ../nature-shared/core/nature-results-discussion.md
    - condition: drafting, restructuring, or auditing any scientific Discussion; choosing the opening anchor and reverse-funnel movement; positioning findings against prior work; calibrating modal verbs or hedging; writing claim-specific limitations; or deriving future work from a named uncertainty
      path: ../nature-shared/core/discussion-argument-language.md
    - condition: target is flagship Nature, Nature Communications, Nature Machine Intelligence, or another Nature Portfolio title and the user is drafting or restructuring the Introduction or whole-manuscript narrative; building a fast problem funnel, exact knowledge gap, literature tension, question-first novelty, compact study roadmap, or Introduction–Results alignment
      path: ../nature-shared/core/nature-introduction.md
    - condition: target is flagship Nature, Nature Communications, Nature Machine Intelligence, or another Nature Portfolio title and the user is drafting or restructuring the abstract; compressing the manuscript into a discovery-centred evidence chain; selecting one main claim, one or two decisive supports, optional core numbers, or a bounded field-level payoff
      path: ../nature-shared/core/nature-abstract.md
    - condition: needs section-level structure, argument order, or published-article patterns
      path: references/article-architecture.md
    - condition: genre-aware 2025 Nat Commun empirical structure, quantified connector/diction preferences, or research/review/perspective/comment/benchmark differences
      path: references/nat-comms-2025-corpus.md
    - condition: drafting/revising abstract; especially challenge-contribution forms
      path: references/abstract.md
    - condition: drafting/revising a Nature-family broad-audience summary paragraph or introduction opening
      path: references/nature-summary-paragraph.md
    - condition: drafting/revising introduction, task framing, technical challenge, contribution framing
      path: references/introduction.md
    - condition: rebuilding related work as topic synthesis
      path: references/related-work.md
    - condition: writing method sections, pipeline modules, module motivation, technical advantages
      path: references/method.md
    - condition: planning/writing experiments around baselines, ablations, metrics
      path: references/experiments.md
    - condition: writing a bounded conclusion with contribution, evidence, impact, limitation
      path: references/conclusion.md
    - condition: user asks whether a paragraph flows; use reverse outlining
      path: references/paragraph-flow.md
    - condition: final manuscript self-review, rejection-risk audit, claim-evidence alignment
      path: references/paper-review.md
    - condition: initial cover letter, title page, highlights, declarations, suggested reviewers, complete first-submission package, or submission-readiness audit
      path: references/submission-package.md
    - condition: flagship Nature Article formatting, initial-submission package, submission-readiness audit, stage classification, or exact title/text/display/reference limits
      path: ../nature-shared/journal-formats/nature.md
    - condition: Nature Machine Intelligence article-type selection, exact word/display limits, initial-submission package, stage classification, data/code duties, or production preflight
      path: ../nature-shared/journal-formats/nature-machine-intelligence.md
    - condition: human or animal ethics, clinical research, reporting summaries, image integrity, structures, chemistry, taxonomy, geological, archaeological, or palaeontological compliance is involved
      path: ../nature-shared/core/research-compliance.md
    - condition: deeper Chinese-author repair patterns beyond the language fragment
      path: references/chinese-author-workflow.md
    - condition: user wants concrete abstract/introduction/method examples
      path: references/examples/index.md

# `nature-writing` Skill

[中文说明](README.md)

`nature-writing` drafts or rebuilds Nature-style manuscript sections and prepares initial-submission packages from author-provided claims, figures, results, notes, or Chinese drafts.

## What To Use It For

- Build titles, abstracts, introductions, result narratives, discussions, conclusions, or significance paragraphs.
- Organize claim-evidence narrative from figures and data.
- Turn Chinese research notes into English manuscript paragraphs.
- Build the background, gap, question, and contribution chain for an Introduction.
- Reorder Results or Discussion at the section level rather than only polishing sentences.
- Classify results as core discovery, necessary support, conclusion-changing qualification, robustness, heterogeneity, provenance, alternative inference, or edge case; allocate them across main text, captions, Methods/source data, and SI; and compress the main text to the shortest sufficient evidence chain.
- Prepare an initial cover letter, title page, highlights, author contributions, availability statements, and other declarations.
- Organize reviewer suggestions, a deliverable matrix, and a pre-submission completeness audit.
- Run the stage-aware official checklist for a flagship `Nature Article`: initial files, title/text/display limits, Extended Data, SI, Reporting Summary, ethics, and specialist materials.
- Apply a dedicated stage-aware `Nature Machine Intelligence` contract covering Article/Analysis word and six-display limits, the required cover letter, up to ten Extended Data items, substantial conference-paper extensions, and data/central-code review access.
- For flagship Nature, Nature Communications, NMI, and other Nature Portfolio titles, structure Results so each subsection advances a claim, permit evidence-bound local interpretation, and make Discussion synthesize across Results rather than re-demonstrate them.
- For any journal's Discussion, organize an explicit function chain from the central-finding anchor through synthesis, literature positioning, interpretation/contribution, claim boundaries, and the next discriminating question; audit modal strength, limitation consequences, and future-work necessity sentence by sentence.
- For every Nature / Nature Portfolio target, make Introductions converge rapidly on an exact unknown, use literature to construct the known–unknown tension, express novelty through the question and answerable design, and align each Introduction question with a Results answer.
- For every Nature / Nature Portfolio target, compress abstracts into a shortest evidence chain—exact gap, answer-enabling design, one main discovery, one or two decisive supports or boundaries, and a bounded payoff—retaining numbers only when they define or materially support the central claim. These three defaults were initially distilled from published NMI papers, with the Results–Discussion guidance further reinforced by flagship Nature comparisons, and generalized as Nature-style guidance; they are not official submission rules.

## Typical Requests

- "Write a Nature-style abstract from these figures and results."
- "Rebuild the logic of this introduction; do not only polish the sentences."
- "Turn these Chinese results into an English Results narrative."
- "Prepare an initial cover letter and complete submission package from this manuscript."

## What You Need To Provide

- Core claim, figures, key results, experimental facts, and target reader.
- Target section, length, language, and terminology that must be preserved.
- Confirmed references, limitations, and conclusions that must not be added.

## Outputs

- Section outline, claim-evidence map, or ready-to-paste prose.
- A Results allocation table, deletion/replacement record, and before/after main-text word-count delta when needed.
- Revision suggestions for novelty, significance, evidence chain, and reader path.
- Facts, references, or figure notes requiring author confirmation.
- Initial-submission materials, editable LaTeX templates, a missing-input checklist, and a `ready / ready_with_author_checks / blocked` status.

## Boundaries

- The skill does not invent experimental results, statistical significance, mechanism explanations, or references.
- If an English draft only needs sentence-level polishing, use `nature-polishing`.
- If claim support requires literature search first, use `nature-citation` or `nature-academic-search`.
- This skill handles first submission; use `nature-response` for revision cover letters, rebuttals, and point-by-point responses.

## Related Skills

- `nature-polishing`: English polishing, translation, and style tightening.
- `nature-citation`: match supporting references for claims.
- `nature-figure`: align figure conclusions and panel design with manuscript narrative.
- `nature-response`: revision cover letters, responses to reviewers, and revision correspondence.
- `nature-reviewer`: simulated review before submission.

# `nature-writing` 技能

[English](README_EN.md)

`nature-writing` 用于根据作者提供的 claims、图表、结果、笔记或中文草稿，起草或重建 Nature 风格手稿章节，并准备首次投稿材料包。

## 适合用它做什么

- 构建标题、摘要、引言、结果叙事、讨论、结论或 significance paragraph。
- 根据图表和数据组织 claim-evidence 叙事。
- 将中文研究笔记转成英文手稿段落。
- 为 Introduction 建立背景、缺口、问题和贡献链。
- 对 Results 或 Discussion 做章节级重排，而不是只做句子润色。
- 将结果分为核心发现、必要支撑、结论性限定、稳健性、异质性、provenance、替代推断和边缘情况，决定主文、图注、Methods/source data 与 SI 的位置，并压缩成最短充分证据链。
- 准备首次投稿 cover letter、title page、highlights、作者贡献、数据/代码可用性和其他声明。
- 整理推荐审稿人、投稿材料矩阵和提交前完整性检查。
- 对旗舰 `Nature Article` 执行分阶段官网清单：初投稿文件、标题/字数/display 限制、Extended Data、SI、Reporting Summary、伦理和专项材料。
- 对 `Nature Machine Intelligence` 执行独立的分阶段投稿合同：Article/Analysis 字数与 6 个 display 上限、必需 cover letter、最多 10 个 Extended Data、会议论文实质扩展、数据与中心代码审查要求。
- 对旗舰 Nature、Nature Communications、NMI 及其他 Nature Portfolio 期刊的 Results，按“每节推进一个 claim”组织证据链，允许直接服务于当前实验的局部解释，并将 Discussion 收束为跨结果综合而非重复论证。
- 对任何期刊的 Discussion，按“中心发现锚点 → 跨结果综合 → 文献定位 → 解释与贡献 → 声称边界 → 下一项判别性问题”组织功能链，并逐句检查情态强度、局限后果和未来工作的必要性。
- 对所有 Nature / Nature Portfolio 目标的 Introduction，快速从具体问题收敛到精确 unknown，用文献建立 known–unknown 张力，以问题和可回答它的设计体现 novelty，并逐项对齐 Introduction 问题链与 Results 答案链。
- 对所有 Nature / Nature Portfolio 目标的 Abstract，按“精确 gap → 可回答的设计 → 主发现 → 1–2 个决定性支撑/边界 → 意义”压缩为最短证据链，数字仅在定义或实质支撑核心 claim 时保留。这三组默认最初来自 NMI 已发表论文语料归纳，其中 Results–Discussion 又经旗舰 Nature 论文对照加强；它们适用于 Nature 风格写作，但都不是官方投稿规则。

## 典型请求

- “根据这些图和结果写一个 Nature 风格 abstract。”
- “帮我重建 introduction 的逻辑，不要只润色句子。”
- “把这些中文结果整理成英文 Results 叙事。”
- “根据这篇稿件准备首次投稿 cover letter 和完整 submission package。”

## 你需要提供

- 核心 claim、图表、关键结果、实验事实和目标读者。
- 目标章节、长度、语言和需要保留的术语。
- 已确认引用、限制条件和不能新增的结论。

## 产出

- 章节大纲、claim-evidence map 或可粘贴正文。
- Results allocation table、删除/替换记录和主文压缩前后字数差（需要时提供）。
- 对 novelty、significance、证据链和读者路径的修改建议。
- 需要作者确认的事实、引用或图表说明。
- 首次投稿材料包、可编辑 LaTeX 模板、缺失信息清单和 `ready / ready_with_author_checks / blocked` 状态。

## 边界

- 不会替作者虚构实验结果、统计意义、机制解释或参考文献。
- 如果已有英文草稿只需要句子级润色，优先使用 `nature-polishing`。
- 如果需要先找文献支撑 claim，优先使用 `nature-citation` 或 `nature-academic-search`。
- 首次投稿材料由本技能处理；返修 cover letter、rebuttal 和逐点回复由 `nature-response` 处理。

## 相关技能

- `nature-polishing`：英文润色、翻译和风格收束。
- `nature-citation`：为 claim 匹配支撑文献。
- `nature-figure`：把图件结论和面板设计对齐到正文叙事。
- `nature-response`：返修 cover letter、response to reviewers 和返修通信材料。
- `nature-reviewer`：投稿前模拟审稿。

# Abstract Writing Guide

## Contents

- [Goal](#goal)
- [Pre-Writing Questions (Important)](#pre-writing-questions-important)
- [Version 1: Challenge -> Contribution](#version-1-challenge-contribution)
- [Version 2: Challenge -> Insight -> Contribution](#version-2-challenge-insight-contribution)
- [Version 3: Multiple Contributions](#version-3-multiple-contributions)
- [Example Bank](#example-bank)
- [Abstract Quality Checklist](#abstract-quality-checklist)


## Goal

Write a strong abstract by doing three things repeatedly:

1. Think through the abstract logic first.
2. Follow one template (Version 1/2/3 below).
3. Revise the abstract many times.

## Pre-Writing Questions (Important)

Answer these before writing:

1. What technical problem do we solve, and why is there no well-established solution? (important)
2. What is our technical contribution?
3. Why can our method work in essence?
4. What technical advantage and new insight do we provide? (important)

## Version 1: Challenge -> Contribution

Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.

### Structure

1. Task.
2. Technical challenge for previous methods.
3. One to two sentences introducing the technical contribution for solving the challenge.
4. Benefits of the technical contribution.
5. Experiment summary.

### Expert Notes

1. Discuss previous work around the technical challenge that we actually solve.
2. For the contribution sentence(s), usually mention the technical term/name only; do not explain every detailed step.
3. The technical term must be easy to understand; readers should not feel a jump.
4. This ability is very important for writing a good abstract.

Version 1 local cite:

1. `references/examples/abstract/template-a.md`

## Version 2: Challenge -> Insight -> Contribution

Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight.

### Structure

1. Task.
2. Technical challenge for previous methods.
3. One sentence introducing the insight for solving the challenge.
4. One to two sentences introducing the technical contribution that implements the insight.
5. Benefits of technical novelty.
6. Experiment summary.

### Expert Notes

1. Discuss previous work around the technical challenge that we actually solve.
2. Introduce the insight in one clear sentence.
3. For the implementation sentence(s), usually mention the technical term/name only; do not explain every detailed step.
4. The technical term must be easy to understand; do not create a jump in reading.
5. This ability is very important for writing a good abstract.

Version 2 local cite:

1. `references/examples/abstract/template-b.md`

## Version 3: Multiple Contributions

Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.

### Structure

1. Task.
2. If needed, one contrast sentence about prior methods.
3. Contribution sentence 1 + technical advantage.
4. Contribution sentence 2 + technical advantage.
5. Contribution sentence 3 + technical advantage.
6. Experiment summary.

### Expert Notes

1. When there are multiple technical contributions, describe each contribution together with its technical advantage.
2. The ability to express "contribution + advantage" in one sentence is very important for writing a good abstract.

Version 3 local cite:

1. `references/examples/abstract/template-c.md`

## Example Bank

1. `references/examples/abstract-examples.md`
2. `references/examples/abstract/template-a.md`
3. `references/examples/abstract/template-b.md`
4. `references/examples/abstract/template-c.md`

## Abstract Quality Checklist

1. Can a reader identify task, challenge, insight/contribution, and results in one pass?
2. Are all major claims supported by experiments?
3. Are technical names self-contained and readable?
4. Is there any sentence that mixes too many messages?

# Article Architecture

## Contents

- [Full-paper argument](#full-paper-argument)
- [Abstract](#abstract)
- [Introduction](#introduction)
- [Results](#results)
- [Discussion](#discussion)
- [Conclusion](#conclusion)
- [Title](#title)


Use this reference when writing or rebuilding manuscript sections. The patterns
come from curated Nature and Nature Communications examples across materials,
energy, construction decarbonization and machine learning. They are structural
patterns, not wording templates.

## Full-paper argument

A strong paper can usually be reduced to:

`field-scale need -> unresolved bottleneck -> proposed move -> decisive evidence
-> broader implication -> boundary`

Before drafting, force the user's material into this chain. If one link is
missing, mark it as missing rather than writing around it.

## Abstract

Recommended paragraph movement:

1. Field-scale context or problem.
2. Why current routes do not fully solve it.
3. What this paper introduces or demonstrates.
4. The strongest result, preferably with quantitative or comparative support.
5. The mechanism, workflow or practical consequence.
6. Bounded implication.

Useful diagnostics:

- If the abstract begins with `Here, we`, it may be missing context.
- If it ends with a broad promise, it may need scope control.
- If it contains no number, comparison or concrete test, it may feel ungrounded.

## Introduction

Use a controlled funnel:

1. Establish the field stake.
2. Explain the bottleneck in existing practice.
3. Treat prior work fairly and specifically.
4. Identify the remaining capability gap.
5. State the present study as a direct response to that gap.

Avoid:

- a literature list without a narrowing logic
- claiming novelty by dismissing prior work
- announcing results before the reader understands the question

## Results

Arrange Results as an evidence ladder:

1. system, workflow or design space overview
2. validation that the platform or assay is credible
3. primary performance or discovery result
4. fair comparison with baseline, standard practice or prior method
5. mechanism, diagnostic analysis or interpretability
6. scale-up, application, generalization or stress test

Subsection opening rule:

`To test [question], we [action].`

Then report the result and evidence. Keep interpretation short unless the
paragraph explicitly transitions toward Discussion.

## Discussion

Discussion should widen from finding to meaning:

1. central advance
2. why the evidence supports it
3. how it changes a workflow, design rule or conceptual boundary
4. how it relates to previous studies
5. what limits or dependencies remain
6. what future work is now plausible

Do not restate every figure. Select the evidence that changes interpretation.

## Conclusion

Use a compact four-part close:

1. This work demonstrates or establishes the main contribution.
2. The decisive evidence is named.
3. The broader implication is stated.
4. The boundary condition is clear.

Conclusions should not introduce new data, new citations or new mechanisms.

## Title

Good titles are concrete and searchable:

`system/object + capability/action + application/consequence`

Examples of title logic:

- material plus function
- method plus task
- process plus scale
- model plus data regime

Avoid vague prestige words such as `novel`, `advanced`, `powerful`, `green`,
`efficient` unless they are made concrete by the rest of the title.

# Chinese Author Workflow

Deep reference for Chinese, mixed Chinese-English, or lab-note input.

This extends `static/fragments/language/zh-to-en.md`. That fragment already holds
the base rule (**translate intent, not syntax** — split each note into claim /
evidence / condition / comparison / implication / limitation, then reorder for
the section) and the common-repair table. Do not repeat those here. Open this
file only when the fragment is not enough: for the drafting sequence below and
the edge-case repairs.

## Drafting from author notes

Use this sequence:

1. Summarize the author's intended claim in Chinese.
2. Identify missing evidence or boundary.
3. Draft the English paragraph.
4. Add short Chinese notes explaining any structural changes.

Do not make the English sound like a literal translation. Make it sound like a
Nature-style manuscript paragraph supported by the user's facts.

## Edge-case repairs (beyond the fragment table)

These patterns come from Chinese having no tense, no obligatory plural, and a
topic-comment structure. They are the ones the base table does not cover.

| Chinese-draft pattern | Repair |
|---|---|
| No tense marking | Choose tense explicitly: past for what was done/found, present for established facts and what the figure shows |
| No obligatory plural | Decide singular vs plural per noun; do not leave bare count nouns (`sample` → `samples` / `each sample`) |
| Stacked `的…的` nested modifiers | Break into a relative clause or a separate sentence; do not pile modifiers before the head noun |
| Topic-comment opener (`关于X，…`) | Rewrite as subject-verb-object; make the topic the grammatical subject or drop it |
| Every sentence opening with `本文 / 我们` | Vary openings; lead some sentences with the result or the object, not the agent |

# Conclusion Writing Guide

## Goal

Close the paper with clear takeaways and credible limitations.

## Structure

1. Restate solved problem and core technical idea.
2. Summarize strongest evidence from experiments.
3. State practical impact or new insight.
4. Add limitation paragraph.
5. End with concrete future direction.

## Limitation Guidance

Prefer limitations tied to task goal/setting boundaries, for example:

1. Data regime limitation (e.g., only short sequences).
2. Assumption limitation (e.g., controlled viewpoints only).
3. Deployment scope limitation (e.g., specific sensor setup).

Avoid framing conclusion around fixable implementation flaws unless they critically define your method's scope.

## Distinguish Limitation Types

1. Technical defect: underperforms strong baselines on key metrics or causes unacceptable tradeoff.
2. Scope limitation: bounded by current task setting and still competitive vs. current SOTA.

## Template

1. This paper addresses [problem] by proposing [method].
2. The key idea is [core insight], which enables [main benefit].
3. Experiments show [main gains] across [datasets/settings].
4. A current limitation is [scope boundary], and extending to [future setting] is an important next step.

# Abstract Examples Index

All abstract example cites should point to the local files below.

1. Version 1 (Challenge -> Contribution)
`Version 1: Introduce the technical challenge, then use one to two sentences to present the technical contribution that solves the challenge.`
`references/examples/abstract/template-a.md`
2. Version 2 (Challenge -> Insight -> Contribution)
`Version 2: Introduce the technical challenge, then use one to two sentences to present the insight for solving the challenge, and then one sentence to present the technical contribution that implements this insight. (Personally recommended.)`
`references/examples/abstract/template-b.md`
3. Version 3 (Multiple Contributions)
`Version 3: When there are multiple technical contributions, describe each contribution together with its technical advantage.`
`references/examples/abstract/template-c.md`

# Abstract Template A Examples (Challenge -> Contribution)

Source scope: your original notes, "Version 1".

```latex
\section{Abstract}
% Task
% Technical challenge for previous methods (discuss around the technical challenge that we solved)
% Introduce the technical contribution for solving the challenge in one to two sentences (usually mention the technical term/name only, without describing every detailed step. The term should be easy to understand and should not create a jump in reading. This ability is very important for writing a good abstract.)
% Introduce the benefits of the technical contribution
% Experiment
```

## Reusable skeleton

1. `[Task sentence]`
2. `However, previous methods suffer from [technical challenge].`
3. `To solve this challenge, we propose [technical contribution name].`
4. `[One more contribution sentence if needed].`
5. `This contribution brings [technical benefit].`
6. `Experiments show [main result].`

# Abstract Template B Examples (Challenge -> Insight -> Contribution)

```latex
\section{Abstract}
% Task
%% Example 1: In recent years, generative models have undergone significant advancement due to the success of diffusion models.
%% Example 2: This paper addresses the challenge of novel view synthesis for a human performer from a very sparse set of camera views.

% Technical challenge for previous methods (discuss around the technical challenge that we solved)
%% Example 1: The success of these models is often attributed to their use of guidance techniques, such as classifier and classifier-free methods, which provides effective mechanisms to tradeoff between fidelity and diversity. However, these methods are not capable of guiding a generated image to be aware of its geometric configuration, e.g., depth, which hinders the application of diffusion models to areas that require a certain level of depth awareness.
%% Example 2: Some recent works have shown that learning implicit neural representations of 3D scenes achieves remarkable view synthesis quality given dense input views. However, the representation learning will be ill-posed if the views are highly sparse.

% Introduce the insight for solving the challenge in one sentence
%% Example 1: To address this limitation, we propose a novel guidance approach for diffusion models that uses estimated depth information derived from the rich intermediate representations of diffusion models.
%% Example 2: To solve this ill-posed problem, our key idea is to integrate observations over video frames.

% Introduce the technical contribution that implements the insight in one to two sentences (usually mention the technical term/name only, without describing every detailed step. The term should be easy to understand and should not create a jump in reading. This ability is very important for writing a good abstract.)
%% Example 1: To do this, we first present a label-efficient depth estimation framework using the internal representations of diffusion models. At the sampling phase, we utilize two guidance techniques to self-condition the generated image using the estimated depth map, the first of which uses pseudo-labeling, and the subsequent one uses a depth-domain diffusion prior.
%% Example 2: To this end, we propose Neural Body, a new human body representation which assumes that the learned neural representations at different frames share the same set of latent codes anchored to a deformable mesh

% Introduce the benefits of technical novelty
%% Example 2: so that the observations across frames can be naturally integrated. The deformable mesh also provides geometric guidance for the network to learn 3D representations more efficiently.

% Experiment
```

## Given example pattern 2

1. `This paper addresses the challenge of novel view synthesis for a human performer from a very sparse set of camera views.`
2. `... representation learning will be ill-posed if the views are highly sparse.`
3. `To solve this ill-posed problem, our key idea is to integrate observations over video frames.`
4. `To this end, we propose Neural Body ...`
5. `... observations across frames can be naturally integrated ... provides geometric guidance ...`
6. `Experiments show [main result].`

# Abstract Template C Examples (Multiple Contributions)

```latex
% Task
%% This paper introduces a novel contour-based approach named deep snake for real-time instance segmentation.

%% Unlike some recent methods that directly regress the coordinates of the object boundary points from an image

% Introduce technical contribution and technical advantage in one sentence (this ability is very important for writing a good abstract.)
%% deep snake uses a neural network to iteratively deform an initial contour to match the object boundary, which implements the classic idea of snake algorithms with a learning-based approach.

% Introduce technical contribution and technical advantage in one sentence
%% For structured feature learning on the contour, we propose to use circular convolution in deep snake, which better exploits the cycle-graph structure of a contour compared against generic graph convolution.

% Introduce technical contribution and technical advantage in one sentence
%% Based on deep snake, we develop a two-stage pipeline for instance segmentation: initial contour proposal and contour deformation, which can handle errors in object localization.

% Experiment
```

## Given example pattern (Deep Snake style from your text)

1. `This paper introduces a novel contour-based approach named deep snake for real-time instance segmentation.`
2. `Unlike some recent methods that directly regress the coordinates of the object boundary points from an image ...`
3. `deep snake uses a neural network to iteratively deform an initial contour ...`
4. `For structured feature learning on the contour, we propose circular convolution ...`
5. `Based on deep snake, we develop a two-stage pipeline ...`
6. `Experiments show [main result].`

# Example Bank Index

Use this folder for concrete writing patterns and locally organized cite targets.

## Files

1. Abstract examples index: `references/examples/abstract-examples.md`
2. Introduction examples index: `references/examples/introduction-examples.md`
3. Abstract template files: `references/examples/abstract/template-a.md`, `references/examples/abstract/template-b.md`, `references/examples/abstract/template-c.md`
4. Introduction task/application files: `references/examples/introduction/version-1-task-then-application.md`, `references/examples/introduction/version-2-application-first.md`, `references/examples/introduction/version-3-general-to-specific-setting.md`, `references/examples/introduction/version-4-open-with-challenge.md`
5. Introduction technical-challenge files: `references/examples/introduction/technical-challenge-version-1-existing-task.md`, `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`, `references/examples/introduction/technical-challenge-version-3-novel-task.md`, `references/examples/introduction/novel-task-challenge-decomposition.md`
6. Introduction pipeline files: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`, `references/examples/introduction/pipeline-version-2-two-contributions.md`, `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`, `references/examples/introduction/pipeline-version-4-observation-driven.md`, `references/examples/introduction/pipeline-not-recommended-abstract-only.md`
7. Method examples index: `references/examples/method-examples.md`
8. Method detail files: `references/examples/method/pre-writing-questions.md`, `references/examples/method/module-triad-neural-body.md`, `references/examples/method/neural-body-annotated-figure-text.md`, `references/examples/method/module-design-instant-ngp.md`, `references/examples/method/module-motivation-patterns.md`, `references/examples/method/section-skeleton.md`, `references/examples/method/overview-template.md`, `references/examples/method/example-of-the-three-elements.md`, `references/examples/method/method-writing-common-issues-note.md`

## Usage

1. Pick one template from a section guide.
2. Open the matching examples file.
3. Reuse the sentence logic, not exact wording.
4. Keep citation links in your notes for traceability.

# Introduction Examples Index

All introduction example cites should point to the local files below.

## A. Task and Application Versions

1. Version 1: `references/examples/introduction/version-1-task-then-application.md`
2. Version 2: `references/examples/introduction/version-2-application-first.md`
3. Version 3: `references/examples/introduction/version-3-general-to-specific-setting.md`
4. Version 4: `references/examples/introduction/version-4-open-with-challenge.md`

## B. Technical Challenge Versions

1. Version 1 (existing task): `references/examples/introduction/technical-challenge-version-1-existing-task.md`
2. Version 2 (existing task + traditional insight backing): `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
3. Version 3 (novel task): `references/examples/introduction/technical-challenge-version-3-novel-task.md`
4. Novel-task decomposition examples: `references/examples/introduction/novel-task-challenge-decomposition.md`

## C. Pipeline-Introduction Versions

1. Version 1: `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
2. Version 2: `references/examples/introduction/pipeline-version-2-two-contributions.md`
3. Version 3: `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
4. Version 4: `references/examples/introduction/pipeline-version-4-observation-driven.md`
5. Not recommended pattern: `references/examples/introduction/pipeline-not-recommended-abstract-only.md`

# Introduction Novel-Task Challenge Decomposition


`For novel tasks without direct methods, decompose the challenge into clear requirement/challenge points.`

```latex
% To achieve xx goal, several requirements must be satisfied (or several challenges must be handled).
%% Example: In this work, our goal is to build a model that captures such object intrinsics from a single image. This problem is challenging for three reasons.

% Describe point 1
%% Example: First, we only have a single image. This makes our work fundamentally different from existing works on 3D-aware image generation models [8, 9, 27, 28], which typically require a large dataset of thousands of instances for training. In comparison, the single image contains at most a few dozen instances, making the inference problem highly under-constrained.

% Describe point 2
%% Example: Second, these already limited instances may vary significantly in pixel values. This is because they have different poses and illumination conditions, but neither of these factors are annotated or known. We also cannot resort to existing tools for pose estimation based on structure from motion, such as COLMAP [35], because the appearance variations violate the assumptions of epipolar geometry.

% Describe point 3
%% Example: Finally, the object intrinsics we aim to infer are probabilistic, not deterministic: no two roses in the natural world are identical, and we want to capture a distribution of their geometry, texture, and material to exploit the underlying multi-view information.
```

# Not Recommended: Abstract-Only Method Description in Introduction


`Not recommended: If the method is simple, do not avoid concrete method details in Introduction and only discuss abstract insight to make it look novel.`

Expert note (faithful translation):

1. The craft of this writing template is how to make a simple pipeline look novel.
2. Note: this is not about making the insight look novel, but about making the pipeline steps look novel.
3. In most cases this is not recommended.
4. The better target is to clearly explain how the core contribution is implemented in Introduction.

```latex
% To tackle this problem, we propose a novel 3D GAN training method to generate photo-realistic images irrespective of the viewing angle.

% Introduce key idea
% Our key idea is as follows. To ease the challenging problem of learning photorealistic and multi-view consistent image synthesis, we cast the problem into two subproblems, each of which can be solved more easily.

% Explain why the key idea works, but without concretely discussing the full pipeline (or only discuss abstract benefit)
%% Example: Specifically, we formulate the problem as a combination of two simple discrimination problems, one of which learns to discriminate whether a synthesized image looks real or not, and the other learns to discriminate whether a synthesized image agrees with the camera pose. Unlike the formulations of the previous methods, which try to learn the real image distribution for each pose, or to learn pose estimation, our subproblems are much easier as each of them is analogous to a basic binary classification problem.

% Introduce pipeline modules with new terms but without clearly explaining the full pipeline (or skip concrete pipeline details)
%% Example: Based on this key idea, we propose a dual-branched discriminator, which has two branches for learning photorealism and pose consistency, respectively. As these branches are supervised explicitly for their respective purposes, high-quality images with pose consistency can be produced at each viewing angle, and consequently, the generator creates high-quality images and shapes. (This paragraph does not clearly explain how the pipeline works.)

% Introduce another contribution
%% Example: In addition, we propose a pose-matching loss to give supervision to the discriminator for the pose consistency, by considering a positive pose (i.e., rendering pose or ground truth pose) and a negative pose (i.e., irrelevant pose) for a given image. (This paragraph does not clearly explain how the pipeline works.)

% Explain expected benefit over prior methods
%% Example: For example, the frontal viewpoint is one of the irrelevant poses for a side-view image. As reported in the experiments, this loss helps improve image and shape quality. This can be interpreted as a simplification of a classification problem from a large number of classes into binary, which is composed of positive and negative pairs.
```

# Pipeline Version 1 (One Contribution, Multiple Advantages)


`Version 1: One contribution with multiple advantages, and one teaser figure to present the basic idea.`

```latex
% In this paper, we propose a novel framework …
%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
In this paper, we propose a novel framework/representation, named [method name] for [xxx task].

% Teaser for basic idea
%% Example: The basic idea is illustrated in Figure 2.
The basic idea is illustrated in [xxx Figure].

% One-sentence key novelty/contribution (very important ability)
%% Example: For the implicit fields at different frames, instead of learning them separately, Neural Body generates them from the same set of latent codes.
Our innovation is in [one sentence for key novelty].

% Method details
%% Example: Specifically, we anchor a set of latent codes to the vertices of a deformable human model (SMPL in this work), namely that their spatial locations vary with the human pose. To obtain the 3D representation at a frame, we first transform the code locations based on the human pose, which can be reliably estimated from sparse camera views. Then, a network is designed to regress the density and color for any 3D point based on these latent codes. Both the latent codes and the network are jointly learned from images of all video frames during the reconstruction.
Specifically, [how it works in detail].

% Advantage 1
%% Example: This model is inspired by the latent variable model in statistics, which enables us to effectively integrate observations at different frames.
In contrast to previous methods, [our advantage].

% Advantage 2
%% Example: Another advantage of the proposed method is that the deformable model provides a geometric prior (rough surface location) to enable more efficient learning of implicit fields.
Another advantage of the proposed method is that [another advantage].
```

# Pipeline Version 2 (Two Contributions)


`Version 2: Two contributions, and one teaser figure to present the basic idea.`

```latex
% In this paper, we propose a novel framework …
%% Example: In this paper, we introduce a novel implicit neural representation for dynamic humans, named Neural Body, to solve the challenge of novel view synthesis from sparse views.
In this paper, we propose a novel framework/representation, named [method name] for [xxx task].

% One-sentence key novelty
%% Example: To that end, we propose techniques to represent a given subject with rare token identifiers and fine-tune a pre-trained, diffusion-based text-to-image framework that operates in two steps; generating a low-resolution image from text and subsequently applying super-resolution (SR) diffusion models.
Our innovation is in [one sentence for key novelty].

% Teaser
%% Example: The basic idea is illustrated in Figure 2.
The basic idea is illustrated in [xxx Figure].

% Contribution 1 details
%% Example: We first fine-tune the low-resolution text-to-image model with the input images and text prompts containing a unique identifier followed by the class name of the subject (e.g., “A [V] dog”).
Specifically, [how contribution 1 works].

% Advantage of contribution 1
%% Example: This model is inspired by the latent variable model in statistics, which enables us to effectively integrate observations at different frames.
In contrast to previous methods, [advantage of contribution 1].

% Challenge motivating contribution 2
%% Example: In order to prevent overfitting and language drift [35, 40] that cause the model to associate the class name (e.g., “dog”) with the specific instance
However, [another technical challenge].

% Contribution 2 details
%% Example: we propose an autogenous, class-specific prior preservation loss, which leverages the semantic prior on the class that is embedded in the model, and encourages it to generate diverse instances of the same class as our subject.
Specifically, [how contribution 2 works].
```

# Pipeline Version 3 (New Module on Existing Pipeline)


`Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`

```latex
% In this paper, we propose a learning-based snake algorithm, named deep snake, for real-time instance segmentation.

% Inspired by previous methods [21, 25], deep snake takes an initial contour as input and deforms it by regressing vertex-wise offsets.

% Our innovation is introducing the circular convolution for efficient feature learning on a contour, as illustrated in Figure 1.

% We observe that the contour is a cycle graph that consists of a sequence of vertices connected in a closed cycle. Since every vertex has the same degree equal to two, we can apply the standard 1D convolution on the vertex features.

% Considering that the contour is periodic, deep snake introduces the circular convolution, which indicates that an aperiodic function (1D kernel) is convolved in the standard way with a periodic function (features defined on the contour).

% The kernel of circular convolution encodes not only the feature of each vertex but also the relationship among neighboring vertices. In contrast, the generic GCN performs pooling to aggregate information from neighboring vertices. The kernel function in our circular convolution amounts to a learnable aggregation function, which is more expressive and results in better performance than using a generic GCN, as demonstrated by our experimental results in Section 5.2.
```

# Pipeline Version 4 (Observation-Driven Contribution)


`Version 4: Contribution comes from one important observation. Introduce key innovation first, then intuitive observation as motivation, then method details, then benefits.`

```latex
% In this paper, we propose a learning-based snake algorithm, named deep snake, for real-time instance segmentation.

% Our innovation is introducing the circular convolution for efficient feature learning on a contour, as illustrated in Figure 1.

% We observe that the contour is a cycle graph that consists of a sequence of vertices connected in a closed cycle. Since every vertex has the same degree equal to two, we can apply the standard 1D convolution on the vertex features.

% Considering that the contour is periodic, deep snake introduces the circular convolution, which indicates that an aperiodic function (1D kernel) is convolved in the standard way with a periodic function (features defined on the contour).

% The kernel of circular convolution encodes not only the feature of each vertex but also the relationship among neighboring vertices. In contrast, the generic GCN performs pooling to aggregate information from neighboring vertices. The kernel function in our circular convolution amounts to a learnable aggregation function, which is more expressive and results in better performance than using a generic GCN, as demonstrated by our experimental results in Section 5.2.
```

# Technical Challenge Version 1 (Existing Task, Existing Methods)


`Version 1: For existing tasks with existing methods, discuss the challenge chain from traditional methods to recent methods and finally to the challenge we solve.`

```latex
% Discuss general technical challenges of this task (to lead into recent methods)
%% Example 1: This problem is quite challenging from many perspectives, including object detection under severe occlusions, variations in lighting and appearance, and cluttered background objects.
%% Example 2: This problem is particularly challenging due to the inherent ambiguity on acquiring human geometry, materials and motions from images.
This problem is particularly challenging due to several factors, including [xxx reason], [xxx reason], and [xxx reason].

% Briefly introduce one class of traditional methods, then discuss their technical challenge
%% Example: Traditional methods have shown that pose estimation can be achieved by establishing the correspondences between an object image and the object model.
To overcome these challenges, traditional methods [how they work], [what they achieve].

%% Example: They rely on hand-crafted features, which are not robust to image variations and background clutters.
However, they [technical challenge they face].

% Briefly introduce one class of recent methods 1 (optional), then discuss their challenge
%% Example: Deep learning based methods train end-to-end neural networks that take an image as input and output its corresponding pose.
Recently, [xxx methods] [how they work], [what they achieve].

%% Example: However, generalization remains as an issue, as it is unclear that such end-to-end methods learn sufficient feature representations for pose estimation.
However, they [limitation], because [xxx technical reason].

% Briefly introduce one class of recent methods 2, then discuss their challenge (must lead to our solved challenge)
%% Example: Some recent methods use CNNs to first regress 2D keypoints and then compute 6D pose parameters using the Perspective-n-Point (PnP) algorithm. In other words, the detected keypoints serve as an intermediate representation for pose estimation. Such two-stage approaches achieve state-of-the-art performance, thanks to robust detection of keypoints.
To overcome this challenge, [xxx methods] [how they work], [what they achieve].

%% Example: However, these methods have difficulty in tackling occluded and truncated objects, since part of their keypoints are invisible. Although CNNs may predict these unseen keypoints by memorizing similar patterns, generalization remains difficult.
However, they [limitation], because [xxx technical reason].
```

# Technical Challenge Version 2 (Existing Task, Insight Backed by Traditional Methods)


`Version 2: For existing tasks, if our technical insight was used in traditional methods, discuss that line to provide conceptual backing.`

```latex
% Introduce one class of traditional/recent methods and discuss their technical challenge (to lead to our insight)
%% Example (Deep Snake): Most of the state-of-the-art instance segmentation methods perform pixel-wise segmentation within a bounding box given by an object detector.
%% Example (ManhattanSDF): Given input images, traditional methods generally estimate the depth map for each image based on the multi-view stereo (MVS) algorithms and then fuse estimated depth maps into 3D models.
Traditional/recent methods [how they work], [what they achieve].

%% Example (Deep Snake): They may be sensitive to the inaccurate bounding box. Moreover, representing an object shape as dense binary pixels generally results in costly post-processing.
%% Example (ManhattanSDF): Although these methods achieve successful reconstruction in most cases, they have difficulty in handling low-textured regions, e.g., floors and walls of indoor scenes, due to the unreliable stereo matching in these regions.
However, they [limitation], because [xxx technical reason].

% Discuss traditional methods that used an insight similar to ours (implicitly backing our idea)
%% Example (Deep Snake): An alternative shape representation is the object contour, which is a set of vertices along the object silhouette. In contrast to pixel-based representation, a contour is not limited within a bounding box and has fewer parameters. Such a contour-based representation has long been used in image segmentation since the seminal work by Kass et al., which is well known as snakes or active contours.
%% Example (ManhattanSDF): To improve the reconstruction of low-textured regions, a typical approach is leveraging the planar prior of manmade scenes, which has long been explored in literature. A renowned example is the Manhattanworld assumption, i.e., the surfaces of man-made scenes should be aligned with three dominant directions.
To overcome this problem, a typical approach is [xxx insight], which has long been explored in literature.

These methods [how they work].

%% Example (Deep Snake): While many variants have been developed in literature, these methods are prone to local optima as the objective functions are handcrafted and typically nonconvex.
%% Example (ManhattanSDF): However, all of them focus on optimizing per-view depth maps instead of the full scene models in 3D space. As a result, depth estimation and plane segmentation could still be inconsistent among views, yielding suboptimal reconstruction quality as demonstrated by our experimental results in Section 5.3.
However, they [limitation], because [xxx technical reason].

% Then discuss newer methods and their remaining challenge (must lead to our solved challenge)
%% Example: There is a recent trend to represent 3D scenes as implicit neural representations and learn the representations from images with differentiable renderers. In particular, [49, 54, 55] use a signed distance field (SDF) to represent the scene and render it into images based on the sphere tracing or volume rendering. Thanks to the well-defined surfaces of SDFs, they recover high-quality 3D geometries from images.
To overcome this challenge, [xxx methods] [how they work], [what they achieve].

%% Example: However, these methods essentially rely on the multi-view photometric consistency to learn the SDFs. So they still suffer from poor performance in low-textured planar regions, as shown in Figure 1, as many plausible solutions may satisfy the photometric constraint in low-textured planar regions.
However, they [limitation], because [xxx technical reason].
```

# Technical Challenge Version 3 (Novel Task)


`Version 3: For novel tasks without direct methods, define the challenge directly and decompose it by requirement/challenge points.`

```latex
% To achieve xx goal, several requirements/challenges must be satisfied.
%% Example: In this work, our goal is to build a model that captures such object intrinsics from a single image. This problem is challenging for three reasons.

% Describe point 1
%% Example: First, we only have a single image. This makes our work fundamentally different from existing works on 3D-aware image generation models [8, 9, 27, 28], which typically require a large dataset of thousands of instances for training. In comparison, the single image contains at most a few dozen instances, making the inference problem highly under-constrained.

% Describe point 2
%% Example: Second, these already limited instances may vary significantly in pixel values. This is because they have different poses and illumination conditions, but neither of these factors are annotated or known. We also cannot resort to existing tools for pose estimation based on structure from motion, such as COLMAP [35], because the appearance variations violate the assumptions of epipolar geometry.

% Describe point 3
%% Example: Finally, the object intrinsics we aim to infer are probabilistic, not deterministic: no two roses in the natural world are identical, and we want to capture a distribution of their geometry, texture, and material to exploit the underlying multi-view information.
```

See also:
1. `references/examples/introduction/novel-task-challenge-decomposition.md`

# Introduction Version 1: Task First, Then Application


`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`

```latex
% Introduce Task (if the task is very familiar, this part can be skipped)
%% Example: Object pose estimation aims to estimate object's orientation and translation relative to a canonical frame from a single image.
[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].

% Introduce Application
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
```

# Introduction Version 2: Application First


`Version 2: If the task is already familiar to most readers, introduce applications directly.`

```latex
% Introduce Application
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].
```

# Introduction Version 3: General Application -> Specific Setting


`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`

```latex
% Introduce applications of the general task
%% Example: Accurate pose estimation is essential for a variety of applications such as augmented reality, autonomous driving and robotic manipulation.
[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].

% Introduce the specific task setting
%% Example: This paper focuses on the specific setting of recovering the 6DoF pose of an object, i.e., rotation and translation in 3D, from a single RGB image of that object.
This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].
```

# Introduction Version 4: Open with Application and Challenge


`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods.`

Expert notes (faithful translation):

1. It is often good if the opening paragraph already states what we want to solve.
2. But this style requires suitable conditions and is less common.
3. Usually, several prior-method paragraphs are still needed before the target challenge becomes clear.

```latex
% Introduce Application
%% Example 1: Reconstructing 3D scenes from multi-view images is a cornerstone of many applications such as augmented reality, robotics, and autonomous driving.
%% Example 2: Instance segmentation is the cornerstone of many computer vision tasks, such as video analysis, autonomous driving, and robotic grasping, which require both accuracy and efficiency.

% Use previous methods to expose the target technical challenge
%% Example 1: Given input images, traditional methods [43, 44, 59] generally estimate the depth map for each image based on the multi-view stereo (MVS) algorithms and then fuse estimated depth maps into 3D models. Although these methods achieve successful reconstruction in most cases, they have difficulty in handling low-textured regions, e.g., floors and walls of indoor scenes, due to the unreliable stereo matching in these regions.
%% Example 2: Most of the state-of-the-art instance segmentation methods [18, 27, 5, 19] perform pixel-wise segmentation within a bounding box given by an object detector [36], which may be sensitive to the inaccurate bounding box. Moreover, representing an object shape as dense binary pixels generally results in costly post-processing.
```

# Method Examples Index

All method example cites should point to the local files below.

## A. Planning and Writing Workflow

1. Pre-writing questions: `references/examples/method/pre-writing-questions.md`

## B. Module Triad and Module-Level Writing

1. Module triad (Neural Body): `references/examples/method/module-triad-neural-body.md`
2. Neural Body figure text conversion: `references/examples/method/neural-body-annotated-figure-text.md`
3. Module design (Instant-NGP): `references/examples/method/module-design-instant-ngp.md`
4. Module motivation patterns: `references/examples/method/module-motivation-patterns.md`

## C. Section-Level Templates

1. Method section skeleton: `references/examples/method/section-skeleton.md`
2. Overview template: `references/examples/method/overview-template.md`
3. Example of the three elements: `references/examples/method/example-of-the-three-elements.md`

## D. Clarity and Troubleshooting

1. Common issues note: `references/examples/method/method-writing-common-issues-note.md`

# Example of the Three Elements

This example uses `%` comments as annotations.
Each `% ...` annotation explains the paragraph(s) immediately below it.

```latex
\begin{quote}
\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
\end{quote}

\begin{itemize}
\item Module design (data structure)
\item Motivation of this module
\item Technical advantages of this module
\item Module design (forward process)
\end{itemize}

\subsection{3.1. Structured latent codes}

% Module design: introduce the module's data structure
To control the spatial locations of latent codes with the human pose, we anchor these latent codes to a deformable human body model (SMPL) [38]. SMPL is a skinned vertex-based model, which is defined as a function of shape parameters, pose parameters, and a rigid transformation relative to the SMPL coordinate system. The function outputs a posed 3D mesh with 6890 vertices. Specifically, we define a set of latent codes \( Z = \{z_1, z_2, ..., z_{6890}\} \) on vertices of the SMPL model. For the frame \( t \), SMPL parameters \( S_t \) are estimated from the multi-view images \( \{I_t^c \mid c = 1, ..., N_c\} \) using [26]. The spatial locations of the latent codes are then transformed based on the human pose \( S_t \) for the density and color regression. Figure 3 shows an example. The dimension of latent code \( z \) is set to 16 in our experiments.

% Technical advantages of this module
Similar to the local implicit representations [25, 5, 18], the latent codes are used with a neural network to represent the local geometry and appearance of a human. Anchoring these codes to a deformable model enables us to represent a dynamic human. With the dynamic human representation, we establish a latent variable model that maps the same set of latent codes to the implicit fields of density and color at different frames, which naturally integrates observations at different frames.

\subsection{3.2. Code diffusion}

% Motivation of this module
Figure 3(a) shows the process of code diffusion. The implicit fields assign the density and color to each point in the 3D space, which requires us to query the latent codes at continuous 3D locations. This can be achieved with the trilinear interpolation. However, since the structured latent codes are relatively sparse in the 3D space, directly interpolating the latent codes leads to zero vectors at most 3D points. To solve this problem, we diffuse the latent codes defined on the surface to nearby 3D space.

% Module design: introduce module design by describing the module forward process
Inspired by [65, 56, 49], we choose the SparseConvNet [21] to efficiently process the structured latent codes, whose architecture is described in Table 1. Specifically, based on the SMPL parameters, we compute the 3D bounding box of the human and divide the box into small voxels with voxel size of \( 5mm \times 5mm \times 5mm \). The latent code of a non-empty voxel is the mean of latent codes of SMPL vertices inside this voxel. SparseConvNet utilizes 3D sparse convolutions to process the input volume and output latent code volumes with \( 2\times, 4\times, 8\times, 16\times \) downsampled sizes. With the convolution and downsampling, the input codes are diffused to nearby space. Following [56], for any point in 3D space, we interpolate the latent codes from multi-scale code volumes of network layers 5, 9, 13, 17, and concatenate them into the final latent code. Since the code diffusion should not be affected by the human position and orientation in the world coordinate system, we transform the code locations to the SMPL coordinate system.

For any point \( \mathbf{x} \) in 3D space, we query its latent code from the latent code volume. Specifically, the point \( \mathbf{x} \) is first transformed to the SMPL coordinate system, which aligns the point and the latent code volume in 3D space. Then, the latent code is computed using the trilinear interpolation. For the SMPL parameters \( S_t \), we denote the latent code at point \( \mathbf{x} \) as \( \psi(\mathbf{x}, Z, S_t) \). The code vector is passed into MLP networks to predict the density and color for point \( \mathbf{x} \).

\subsection{3.3. Density and color regression}

Figure 3(b) overviews the regression of density and color for any point in 3D space. The density and color fields are represented by MLP networks. Details of network architectures are described in the supplementary material.

% Module design: introduce module design by describing the module forward process
\textbf{Density model.} For the frame \( t \), the volume density at point \( \mathbf{x} \) is predicted as a function of only the latent code \( \psi(\mathbf{x}, Z, S_t) \), which is defined as:

\[
\sigma_t(\mathbf{x}) = M_{\sigma}(\psi(\mathbf{x}, Z, S_t)),
\tag{1}
\]

where \( M_{\sigma} \) represents an MLP network with four layers.

% Module design: introduce the module's data structure
\textbf{Color model.} Similar to [37, 44], we take both the latent code \( \psi(\mathbf{x}, Z, S_t) \) and the viewing direction \( \mathbf{d} \) as input for the color regression. To model the location-dependent incident light, the color model also takes the spatial location \( \mathbf{x} \) as input. We observe that temporally-varying factors affect the human appearance, such as secondary lighting and self-shadowing. Inspired by the auto-decoder [48], we assign a latent embedding \( \ell_t \) for each video frame \( t \) to encode the temporally-varying factors.

% Module design: introduce module design by describing the module forward process
Specifically, for the frame \( t \), the color at \( \mathbf{x} \) is predicted as a function of the latent code \( \psi(\mathbf{x}, Z, S_t) \), the viewing direction \( \mathbf{d} \), the spatial location \( \mathbf{x} \), and the latent embedding \( \ell_t \). Following [51, 44], we apply the positional encoding to both the viewing direction \( \mathbf{d} \) and the spatial location \( \mathbf{x} \), which enables better learning of high frequency functions. The color model at frame \( t \) is defined as:

\[
c_t(\mathbf{x}) = M_c(\psi(\mathbf{x}, Z, S_t), \gamma_d(\mathbf{d}), \gamma_x(\mathbf{x}), \ell_t),
\tag{2}
\]

where \( M_c \) represents an MLP network with two layers, and \( \gamma_d \) and \( \gamma_x \) are positional encoding functions for viewing direction and spatial location, respectively. We set the dimension of \( \ell_t \) to 128 in experiments.

\subsection{3.4. Volume rendering}

% Module design: introduce module design by describing the module forward process
Given a viewpoint, we utilize the classical volume rendering techniques to render the Neural Body into a 2D image. The pixel colors are estimated via the volume rendering integral equation [27] that accumulates volume densities and colors along the corresponding camera ray. In practice, the integral is approximated using numerical quadrature [41, 44]. Given a pixel, we first compute its camera ray \( \mathbf{r} \) using the camera parameters and sample \( N_k \) points \( \{\mathbf{x}_k\}_{k=1}^{N_k} \) along camera ray \( \mathbf{r} \) between near and far bounds. The scene bounds are estimated based on the SMPL model. Then, Neural Body predicts volume densities and colors at these points. For the video frame \( t \), the rendered color \( \hat{C}_t(\mathbf{r}) \) ...
```

# Method Writing Common Issues (Reference Note)

Original source mentioned in your notes:

1. `Method writing common issues (PDF in your source notes)`

Usage recommendation:

1. Use this reference as a troubleshooting checklist after drafting Method.
2. Prioritize unclear motivation, broken flow, missing implementation details, and inconsistent terms.

# Module Design Example

This example uses `%` comments as annotations.
Each `% ...` annotation explains the paragraph(s) immediately below it.

```latex
\begin{quote}
\textbf{Annotation rule.} In this example, each line starting with \% labels the role of the paragraph(s) directly below it.
\end{quote}

\begin{itemize}
\item Motivation of this module
\item Module design (data structure)
\item Module design (forward process)
\end{itemize}

\section{3 \quad MULTIRESOLUTION HASH ENCODING}

% Motivation of this module
Given a fully connected neural network \(m(y;\Phi)\), we are interested in an encoding of its inputs \(y=\operatorname{enc}(x;\theta)\) that improves the approximation quality and training speed across a wide range of applications without incurring a notable performance overhead.

% Module design: introduce the module's data structure
Our neural network not only has trainable weight parameters \(\Phi\), but also trainable encoding parameters \(\theta\). These are arranged into \(L\) levels, each containing up to \(T\) feature vectors with dimensionality \(F\). Typical values for these hyperparameters are shown in Table 1. Figure 3 illustrates the steps performed in our multiresolution hash encoding. Each level (two of which are shown as red and blue in the figure) is independent and conceptually stores feature vectors at the vertices of a grid, the resolution of which is chosen to be a geometric progression between the coarsest and finest resolutions \([N_{\min},N_{\max}]\):

\[
N_l := \left\lfloor N_{\min}\cdot b^l \right\rfloor, \tag{2}
\]

\[
b := \exp\!\left(\frac{\ln N_{\max}-\ln N_{\min}}{L-1}\right). \tag{3}
\]

\(N_{\max}\) is chosen to match the finest detail in the training data. Due to the large number of levels \(L\), the growth factor is usually small. Our use cases have \(b\in[1.26,2]\).

% Module design: introduce module design by describing the module forward process
Consider a single level \(l\). The input coordinate \(x\in\mathbb{R}^d\) is scaled by that level's grid resolution before rounding down and up:
\[
\lfloor x_l \rfloor := \lfloor x\cdot N_l \rfloor,\quad
\lceil x_l \rceil := \lceil x\cdot N_l \rceil.
\]

\(\lfloor x_l \rfloor\) and \(\lceil x_l \rceil\) span a voxel with \(2^d\) integer vertices in \(\mathbb{Z}^d\). We map each corner to an entry in the level's respective feature vector array, which has fixed size of at most \(T\). For coarser levels where a dense grid requires fewer than \(T\) parameters, i.e. \((N_l+1)^d \le T\), this mapping is 1:1. At finer levels, we use a hash function \(h:\mathbb{Z}^d\rightarrow\mathbb{Z}_T\) to index into the array, effectively treating it as a hash table, although there is no explicit collision handling. We rely instead on the gradient-based optimization to store appropriate sparse detail in the array, and the subsequent neural network \(m(y;\Phi)\) for collision resolution. The number of trainable encoding parameters \(\theta\) is therefore \(O(T)\) and bounded by \(T\cdot L\cdot F\), which in our case is always \(T\cdot16\cdot2\) (Table 1).

We use a spatial hash function [Teschner et al. 2003] of the form
\[
h(x)=\left(\bigoplus_{i=1}^{d} x_i\pi_i\right)\bmod T, \tag{4}
\]
where \(\oplus\) denotes the bit-wise XOR operation and \(\pi_i\) are unique, large prime numbers. Effectively, this formula XORs the results of a per-dimension linear congruential (pseudo-random) permutation [Lehmer 1951], \emph{decorrelating} the effect of the dimensions on the hashed value. Notably, to achieve (pseudo-)independence, only \(d-1\) of the \(d\) dimensions must be permuted, so we choose \(\pi_1:=1\) for better cache coherence, \(\pi_2=2{,}654{,}435{,}761\), and \(\pi_3=805{,}459{,}861\).

Lastly, the feature vectors at each corner are \(d\)-linearly interpolated according to the relative position of \(x\) within its hypercube, i.e. the interpolation weight is \(w_l := x_l-\lfloor x_l \rfloor\).

Recall that this process takes place independently for each of the \(L\) levels. The interpolated feature vectors of each level, as well as auxiliary inputs \(\xi\in\mathbb{R}^E\) (such as the encoded view direction and textures in neural radiance caching), are concatenated to produce \(y\in\mathbb{R}^{LF+E}\), which is the encoded input \(\operatorname{enc}(x;\theta)\) to the MLP \(m(y;\Phi)\).

\textbf{Performance vs. quality.} Choosing the hash table size \(T\) provides a trade-off between performance, memory and quality. Higher values of \(T\) result in higher quality and lower performance. The memory ...
```

# Module Motivation Writing Patterns


`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`

Typical opening sentences:

1. `A remaining problem/challenge is ...`
2. `However, we ...`
3. `Previous methods have difficulty in ...`

Usage note:

1. State the specific failure before introducing the module.
2. Keep motivation independent from implementation details.

# Module Triad Example (Neural Body)

`Use Neural Body to understand the three elements of a module: design, motivation, and technical advantages.`

Local source references:

1. Annotated figure showing motivation/design/advantages split.
3. Text-converted annotation notes: `references/examples/method/neural-body-annotated-figure-text.md`

Triad mapping template:

1. Module design: what representation/network is built and how forward process runs.
2. Motivation: what unresolved challenge requires this module.
3. Technical advantages: why this module performs better than alternatives.

Direct usage:

1. Read `neural-body-annotated-figure-text.md` to map each paragraph to one triad element.
2. Rebuild your own Method subsection with the same triad order.

# Neural Body Annotated Figure (Text Conversion)

This file converts the annotated Neural Body figure into reusable writing notes.

## Purpose

Use this mapping to understand how one Method section can explicitly separate:

1. Module motivation
2. Module design (data structure)
3. Module design (forward process)
4. Technical advantages

## Block-by-Block Mapping

### Section 3.1: Structured Latent Codes

1. **Module design (data structure)**
- The paragraph defines structured latent codes anchored to the deformable human model (SMPL).
- It explains what is constructed (latent codes + their anchor positions + frame-dependent transformation by pose).

2. **Technical advantages**
- The paragraph explains why this design works better: dynamic-human representation and cross-frame integration of observations.
- It highlights why anchoring codes to deformable geometry is beneficial.

### Section 3.2: Code Diffusion

1. **Motivation of this module**
- The paragraph states the remaining problem: direct interpolation of sparse structured codes leads to near-zero vectors at many 3D points.
- This motivates diffusion from surface codes to nearby 3D space.

2. **Module design (forward process)**
- The paragraph explains the execution pipeline: build sparse latent volumes, run sparse convolutions, interpolate latent codes at query points, and feed codes to prediction networks.
- This is a canonical input -> steps -> output module description.

### Section 3.3: Density and Color Regression

1. **Module design (forward process) for density model**
- The density paragraph defines how density is regressed from latent code and frame condition.

2. **Module design (data structure) for color model**
- The color paragraph introduces required inputs/embeddings (latent code, view direction, spatial location, temporal embedding).

3. **Module design (forward process) for color model**
- The next paragraph describes how those inputs are encoded and passed into the color MLP for final color prediction.

### Section 3.4: Volume Rendering

1. **Module design (forward process)**
- The paragraph describes ray sampling and volume integration to render image outputs from predicted density/color fields.

## Reusable Writing Pattern from This Figure

For each module subsection, follow this order:

1. `Motivation`: state unresolved challenge and technical reason.
2. `Design-1`: define structure/representation/network.
3. `Design-2`: describe forward process in execution order.
4. `Advantage`: explain why this module improves over alternatives.

## Suggested Paragraph Starters

1. Motivation: `A remaining challenge is ...`
2. Data structure design: `We represent ... with ...`
3. Forward process: `Given [input], we first ... then ... finally ...`
4. Technical advantage: `Compared with previous methods, this design ... because ...`

# Method Overview Template


`Overview usually includes setting, core contribution, optional figure pointer, and subsection map.`

```latex
% Overview
% One or two sentences for setting
%% Example 1: Given a sparse multi-view video of a performer, our task is to generate a free-viewpoint video of the performer.
%% Example 2: Given an image, the task of pose estimation is to detect objects and estimate their orientations and translations in the 3D space.

% One or two sentences for core contribution
%% Example 1: We build upon prior work for static scenes [46], to which we add the notion of time, and estimate 3D motion by explicitly modeling forward and backward scene flow as dense 3D vector fields.
%% Example 2: Inspired by [21, 25], we perform object segmentation by deforming an initial contour to match object boundary.
%% Example 3: Inspired by recent methods [29, 30, 36], we estimate the object pose using a two-stage pipeline: we first detect 2D object keypoints using CNNs and then compute 6D pose parameters using the PnP algorithm. Our innovation is in a new representation for 2D object keypoints as well as a modified PnP algorithm for pose estimation.

% If pipeline/framework is novel, point to figure
%% Example: The overview of the proposed model is illustrated in Figure 3.

% Explain what Section 3.1 covers
%% Example 1: Neural Body starts from a set of structured latent codes attached to the surface of a deformable human model (Section 3.1).
%% Example 2: In this section, we first describe how to model 3D scenes with MLP maps (Section 3.1).

% Explain what Section 3.2 covers
%% Example 1: The latent code at any location around the surface can be obtained with a code diffusion process (Section 3.2) and then decoded to density and color values by neural networks (Section 3.3).
%% Example 2: Then, Section 3.2 discusses how to represent volumetric videos with dynamic MLP maps.

% Explain what Section 3.3 covers
%% Example 3: Finally, we introduce some strategies to speed up the rendering process (Section 3.3).
```

# Method Pre-Writing Questions


`Before writing Method, answer: (1) what modules exist, and (2) for each module, what is its workflow, why is it needed, and why does it work.`

```text
Questions:
(1) What modules are in the method?
(2) For each module, answer three questions:
    - What is this module's workflow?
    - Why do we need this module?
    - Why does this module work?
```

Recommended action:

1. Organize answers in a mind map or table before writing paragraphs.

# Method Section Skeleton

```latex
\section{Method}
% Overview
% Section 3.1
% Section 3.2
% Section 3.3
```

# Experiments Writing Guide

## Contents

- [Goal](#goal)
- [Three Core Questions](#three-core-questions)
- [Experiment Planning](#experiment-planning)
- [Experiment Section Decomposition](#experiment-section-decomposition)
- [Figure/Table Writing Rules](#figuretable-writing-rules)
- [Recommended Ablation Package](#recommended-ablation-package)
- [Experimental Rigor Checklist](#experimental-rigor-checklist)


## Goal

Convince reviewers with complete evidence on effectiveness, causality, and practical value.

## Three Core Questions

1. Is the method better than strong baselines?
   - Run comparison experiments against strong and recent baselines.
   - Report standard metrics on the main benchmark(s).
   - Include SOTA or strongest public methods, not only weak baselines.
   - Keep protocol fair (same data split, preprocessing, and evaluation settings).
2. Which modules/design choices make the gain?
   - Run ablation studies for each key module/design choice.
   - Use remove/replace/disable variants and report delta to full model.
   - Include component interaction ablations when modules are coupled.
3. How far can the method generalize under harder settings?
   - Run demos/evaluations on harder or out-of-distribution settings.
   - Add stress-test scenarios (more complex scenes, rarer cases, noisier inputs, or stricter constraints).
   - Report both gains and failure modes to show realistic boundaries.

## Experiment Planning

```mermaid
flowchart TB
    A["Key Paper Claims"] --> B["What Contributions Are Claimed?"]
    B --> C1["Contribution 1"]
    B --> C2["Contribution 2"]
    B --> C3["Contribution 3"]
    C1 --> D1["Validation Experiment 1"]
    C2 --> D2["Validation Experiment 2"]
    C3 --> D3["Validation Experiment 3"]

    E["Method Pipeline Figure"] --> F["What Modules and Parameters Matter?"]
    F --> G1["Technical Module 1"]
    F --> G2["Technical Module 2"]
    F --> G3["Key Parameter 1"]
    F --> G4["Key Parameter 2"]
    G1 --> H1["Ablation Study 1"]
    G2 --> H2["Ablation Study 2"]
    G3 --> H3["Ablation Study 3"]
    G4 --> H4["Ablation Study 4"]
```

## Experiment Section Decomposition

```mermaid
flowchart TB
    S1["Experimental Setup"] --> S2["Validation Experiment 1"]
    S2 --> S3["Validation Experiment 2"]
    S3 --> S4["Ablation Studies"]
```

## Figure/Table Writing Rules

`Good tables are part of experiment communication quality, not decoration.`

1. Figure captions and table captions are equally important in the writing quality of Experiments.

### Hard rules

1. Put caption above the table.
2. Avoid vertical lines (`|`) in tabular columns.
3. Do not use double rules or dense `\hline` stacks.
4. Use `booktabs` style (`\toprule`, `\midrule`, `\bottomrule`) for clean structure.
5. Use as few horizontal rules as possible; lines should separate groups, not every row.
6. Highlight key numbers (best/second-best or target rows) with subtle color emphasis.

### Readability rules from review practice

1. Label metric direction in column headers (for example `PSNR ↑`, `LPIPS ↓`).
2. Add units when needed so values are interpretable without guessing.
3. Align text columns left; keep numeric columns consistently aligned.
4. Keep numeric precision consistent (same decimal places within a metric column).
5. Group multi-dataset or multi-setting results using `\multicolumn` + `\cmidrule`, not vertical separators.
6. One table, one message: do not mix unrelated results in a single table.
7. If rows represent different attributes/ablations, encode that explicitly in row names or attribute columns.
8. Keep caption focused on setting/protocol/notation, not long discussion.
9. If there is little detail to explain, use one concise sentence to summarize the main result.
10. For single-column figures/tables in two-column papers, prefer placing them in the right column when layout allows, so readers can enter the page from the left-top text without breaking reading flow.

### Minimal LaTeX checklist

1. Add packages in preamble: `\usepackage{booktabs}`, `\usepackage{colortbl,xcolor}` (and optionally `\usepackage{siunitx}` for decimal alignment).
2. Replace `\hline`-heavy style with `\toprule/\midrule/\bottomrule`.
3. Put `\caption{...}` before `\label{...}` and keep caption above.
4. Use restrained highlighting; never color too many cells.

## Recommended Ablation Package

1. One core ablation table for all major contributions.
2. Several focused mini-ablations for module-level design choices.
3. Matching qualitative visual results for each important ablation.

## Experimental Rigor Checklist

1. Are baselines recent and relevant?
2. Are metrics sufficient and standard for this task?
3. Is ablation tied to every key design claim?
4. Are claims in Abstract/Introduction supported by reported numbers?
5. Are limitations of evaluation scope explicitly stated?

# Introduction Writing Guide

## Contents

- [Goal](#goal)
- [Introduction Logic Map](#introduction-logic-map)
- [How to Think About Introduction: Backward First, Then Forward](#how-to-think-about-introduction-backward-first-then-forward)
- [Section Skeleton](#section-skeleton)
- [Part A: Introduce Task and Application](#part-a-introduce-task-and-application)
- [Part B: Introduce Technical Challenge for Previous Methods (Very Important)](#part-b-introduce-technical-challenge-for-previous-methods-very-important)
- [Part C: Introduce Our Pipeline for Solving the Challenge](#part-c-introduce-our-pipeline-for-solving-the-challenge)
- [Example Bank](#example-bank)
- [Quick Quality Checklist](#quick-quality-checklist)


## Goal

Write a strong introduction in three steps:

1. Think through the introduction logic.
2. Apply a suitable template below.
3. Revise the introduction repeatedly.

## Introduction Logic Map

```mermaid
graph LR
  L1[What task are we solving]
  L2[Which metrics should this task improve]
  L3[SOTA methods fail to meet target metrics]
  L4[Root technical issue behind this failure]
  L5[Our technical solution and method pipeline]
  L6[Why the solution works]
  L7[Additional technical contributions]

  R1[Part 1 Task applications and target metrics]
  R2[Part 2 SOTA methods failure and root issue]
  R3[Part 3 Proposed solution and why it works]
  R4[Part 4 Additional contributions and impact]
  R5[Part 5 Experiments]

  L1 --> L2
  L2 --> L3
  L3 --> L4
  L4 --> L5
  L5 --> L6
  L6 --> L7

  R1 --> R2
  R2 --> R3
  R3 --> R4
  R4 --> R5

  L1 --> R1
  L2 --> R1
  L3 --> R2
  L4 --> R2
  L5 --> R3
  L6 --> R3
  L7 --> R4
```

## How to Think About Introduction: Backward First, Then Forward

### Backward reasoning (answer these first)

1. What technical problem do we solve, and why is there no well-established solution? (important)
2. What are the contributions of our pipeline (e.g., a new valuable task, a new valuable metric, a new technical problem, or a new technique)?
3. What are the benefits of our contributions, why can they solve this technical challenge, and what new insight do they bring? (important)
4. How do we use prior methods to lead readers to our solved challenge and our new insight?

### Forward story (write in this order)

1. Introduce the paper's task.
2. Use prior methods to lead to the technical challenge we solve.
3. Present xx contributions to solve this technical challenge.
4. Explain technical advantages of our contributions and explicitly express our new insight. (important)

## Section Skeleton

```latex
\section{Introduction}
% Task and application
% Technical challenge for previous methods (discuss around the technical challenge that we solved. A technical challenge includes both limitation and technical reason)
% Introduce our pipeline for solving the challenge
% Experiment
% Contributions
```

## Part A: Introduce Task and Application

### Version 1

`Version 1: If the task is relatively niche, introduce the task first, then introduce applications.`

Writing structure:

1. Define the task in one clear sentence (`what output` from `what input`).
2. Briefly explain the task objective or scope (optional).
3. Introduce application value with 2-3 representative scenarios.

Sentence skeleton:

1. `[xxx task] targets at recovering/reconstructing/estimating [xxx output] from [xxx input].`
2. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`

Local cite:

1. `references/examples/introduction/version-1-task-then-application.md`

### Version 2

`Version 2: If the task is already familiar to most readers, introduce applications directly.`

Writing structure:

1. Skip formal task definition.
2. Open with application importance in one concise sentence.
3. Optionally append target requirement (e.g., accuracy/efficiency/robustness).

Sentence skeleton:

1. `[xxx task] has a variety of applications such as [xxx], [xxx], and [xxx].`

Local cite:

1. `references/examples/introduction/version-2-application-first.md`

### Version 3

`Version 3: Introduce applications of the general task first, then introduce the specific task setting. (Personally recommended when the setting is relatively new.)`

Writing structure:

1. Start from the general task and why it matters.
2. Narrow down to the specific setting of this paper.
3. Clarify exact input/output and boundary of the setting.

Sentence skeleton:

1. `[general task] has a variety of applications such as [xxx], [xxx], and [xxx].`
2. `This paper focuses on the specific setting of recovering/reconstructing/estimating [xxx output] from [xxx input].`

Local cite:

1. `references/examples/introduction/version-3-general-to-specific-setting.md`

### Version 4

`Version 4: If the task is familiar, introduce applications directly and expose the target technical challenge in the opening paragraph via previous methods (failure cases / target metric improvements).`

Writing structure:

1. Start with task/application importance.
2. Immediately summarize how representative previous methods work.
3. Immediately expose the unresolved failure case + technical reason.
4. Use this opening as a bridge to the later prior-work paragraphs.

Opening-paragraph skeleton:

1. `[Task/application importance sentence].`
2. `Given input ..., previous methods usually ...`
3. `Although they work in many cases, they fail at ... because ...`

Expert note:

1. It is often good if the first paragraph already states what problem you want to solve, instead of requiring several paragraphs of prior work before the challenge appears.
2. This style needs the right conditions and is less common.
3. Typical Version 4 flow: Part 1 (task + application and directly expose challenge via previous methods 1) -> Part 2 (previous methods 2 try to solve it but still fail) -> Part 3 (our method).
4. More common general flow: Part 1 (task + application) -> Part 2 (previous methods 1 + limitation) -> Part 3 (previous methods 2 + limitation; here the target challenge emerges) -> Part 4 (our method).

Local cite:

1. `references/examples/introduction/version-4-open-with-challenge.md`

## Part B: Introduce Technical Challenge for Previous Methods (Very Important)

Purpose:

1. Discuss around the exact technical challenge we solved.
2. Build reader curiosity about how to solve this challenge.
3. Make motivation/benefit of our method clear.

Key logic before writing (faithful translation):

1. First make clear the logic for "leading to the technical challenge we solved".
2. For existing tasks: identify which recent methods have this challenge, why those methods exist, and optionally what earlier challenge they were trying to solve.
3. For novel tasks: at minimum, define the technical challenge solved by our pipeline.

Important warning :

1. Do not first present a naive solution and then describe our improvement over it.
2. That writing makes the work look like a low-score incremental patch.
3. Even if the work is actually incremental, do not write it this way.
4. Why: this writing style can erase reader curiosity and make the idea look straightforward only because the writing hand-holds the reader.

### Technical-Challenge Version 1 (existing task, with existing methods)

`Version 1: For existing tasks, discuss the challenge chain from general challenge -> traditional methods -> recent methods -> remaining challenge that we solve.`

Writing structure:

1. Start with a general challenge statement for this task.
2. Briefly summarize traditional methods and their limitation.
3. Briefly summarize recent methods (1) and their limitation with technical reason.
4. Briefly summarize recent methods (2) and their limitation with technical reason.
5. Ensure the final limitation is exactly the challenge your method solves.

Sentence skeleton:

1. `This problem is particularly challenging due to ...`
2. `To overcome these challenges, traditional methods ... However, they ...`
3. `Recently, ... methods ... However, they ... because ...`
4. `To overcome this challenge, ... methods ... However, they ... because ...`

Local cite:

1. `references/examples/introduction/technical-challenge-version-1-existing-task.md`

### Technical-Challenge Version 2 (existing task + our insight seen in traditional methods)

`Version 2: For existing tasks, when our insight has historical roots in traditional methods, use that line as conceptual backing and then show why new methods still fail.`

Writing structure:

1. Start from mainstream methods and state their limitation.
2. Introduce a classical/traditional line that already contains insight similar to yours.
3. Explain why that classical line is still insufficient.
4. Return to modern methods and show the unresolved technical reason.
5. Bridge to your method naturally.

Sentence skeleton:

1. `Traditional/recent methods ... However, they ... because ...`
2. `To overcome this problem, a typical approach is [insight], which has long been explored ...`
3. `However, these methods still ... because ...`
4. `To overcome this challenge, newer methods ... However, they ... because ...`

Local cite:

1. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`

### Technical-Challenge Version 3 (novel task, no direct methods)

`Version 3: For novel tasks without direct prior methods, define the challenge directly and decompose it into several concrete challenge points.`

Writing structure:

1. State the goal and explain that the problem is challenging for N reasons.
2. Use `First/Second/Finally` to separate independent challenge points.
3. For each point, state the observable limitation and the technical reason.
4. End with a transition to your pipeline.

Sentence skeleton:

1. `In this work, our goal is to ... This problem is challenging for three reasons.`
2. `First, ...`
3. `Second, ...`
4. `Finally, ...`

Local cite:

1. `references/examples/introduction/technical-challenge-version-3-novel-task.md`

## Part C: Introduce Our Pipeline for Solving the Challenge

Key questions before writing:

### For existing tasks

1. What technical challenge does our pipeline solve?
2. What is our technical contribution?
3. Why can our method work in essence?
4. What benefits does our method have over previous methods?

### For novel tasks

1. What technical challenge does our pipeline solve?
2. What is our technical contribution?
3. Why can our method work in essence?

### Pipeline Version 1

`Version 1: One contribution with multiple advantages, and one teaser figure to present the basic idea.`

Writing structure:

1. Introduce one core framework/representation for the target task.
2. Point to teaser figure for the basic idea.
3. State key novelty in one sentence.
4. Explain concrete implementation steps (`Specifically, ...`).
5. State multiple advantages (`In contrast ...`, `Another advantage ...`).

Sentence skeleton:

1. `In this paper, we propose a novel framework/representation, named ..., for ...`
2. `The basic idea is illustrated in Figure ...`
3. `Our innovation is in ...`
4. `Specifically, ...`
5. `In contrast to previous methods, ...`
6. `Another advantage of the proposed method is that ...`

Local cite:

1. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`

### Pipeline Version 2

`Version 2: Two contributions, and one teaser figure to present the basic idea.`

Writing structure:

1. Introduce framework and key novelty sentence.
2. Point to teaser figure.
3. Explain contribution 1 and its advantage.
4. Introduce a remaining challenge.
5. Explain contribution 2 as the response to that challenge.

Sentence skeleton:

1. `In this paper, we propose ...`
2. `Our innovation is in ...`
3. `The basic idea is illustrated in Figure ...`
4. `Specifically, ...` (contribution 1)
5. `In contrast to previous methods, ...`
6. `However, ...` (remaining challenge)
7. `Specifically, ...` (contribution 2)

Local cite:

1. `references/examples/introduction/pipeline-version-2-two-contributions.md`

### Pipeline Version 3

`Version 3: Build on a prior pipeline and introduce one new module, with a teaser figure for the basic idea.`

Writing structure:

1. Start from prior pipeline setup.
2. Introduce one new module as key innovation.
3. Provide an observation that motivates the module design.
4. Explain the module mechanism.
5. Compare against generic alternatives and state why it is better.

Sentence skeleton:

1. `Inspired by previous methods, ...`
2. `Our innovation is introducing ...`
3. `We observe that ...`
4. `Considering that ..., we introduce ...`
5. `In contrast to ..., our module ...`

Local cite:

1. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`

### Pipeline Version 4

`Version 4: Contribution comes from one important observation. Introduce key innovation first, then a listener-friendly observation as motivation, then method details, then benefits.`

Writing structure:

1. State key innovation first.
2. State one intuitive observation as motivation.
3. Explain implementation details.
4. Explain technical advantage and empirical gain.

Sentence skeleton:

1. `Our innovation is ...`
2. `We observe that ...`
3. `Considering that ..., we ...`
4. `This leads to ... and achieves ...`

Local cite:

1. `references/examples/introduction/pipeline-version-4-observation-driven.md`

### Not Recommended Writing

`Not recommended: If the method is simple, do not hide concrete method design in Introduction and only describe abstract insights to make the work look novel.`

Expert note:

1. In this template, the writing craft is about making a simple pipeline sound novel.
2. The key caution: people often make the pipeline steps sound novel, not the real insight.
3. In most cases this is not recommended. The better target is to clearly explain core contribution implementation in Introduction.

Why not recommended (writing structure warning):

1. Presenting only abstract insight without concrete pipeline steps weakens technical clarity.
2. Introducing many new terms without mechanism-level explanation creates a novelty illusion.
3. Reviewers may interpret this as shallow or incremental work.

Local cite:

1. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`

## Example Bank

1. `references/examples/introduction-examples.md`
2. `references/examples/introduction/version-1-task-then-application.md`
3. `references/examples/introduction/version-2-application-first.md`
4. `references/examples/introduction/version-3-general-to-specific-setting.md`
5. `references/examples/introduction/version-4-open-with-challenge.md`
6. `references/examples/introduction/technical-challenge-version-1-existing-task.md`
7. `references/examples/introduction/technical-challenge-version-2-existing-task-insight-backed-by-traditional.md`
8. `references/examples/introduction/technical-challenge-version-3-novel-task.md`
9. `references/examples/introduction/pipeline-version-1-one-contribution-multi-advantages.md`
10. `references/examples/introduction/pipeline-version-2-two-contributions.md`
11. `references/examples/introduction/pipeline-version-3-new-module-on-existing-pipeline.md`
12. `references/examples/introduction/pipeline-version-4-observation-driven.md`
13. `references/examples/introduction/pipeline-not-recommended-abstract-only.md`

## Quick Quality Checklist

1. Does the first sentence of each paragraph state its message?
2. Does each paragraph carry one message only?
3. Are technical challenge, technical reason, and solved mechanism all explicit?
4. Are claims in Introduction aligned with experiment evidence?
5. Is terminology stable across all sections?

# Method Writing Guide

## Contents

- [Goal](#goal)
- [Pre-Writing Questions](#pre-writing-questions)
- [Method Writing Steps](#method-writing-steps)
- [Three Elements of a Pipeline Module](#three-elements-of-a-pipeline-module)
- [Method Content Decomposition](#method-content-decomposition)
- [How to Write Module Design](#how-to-write-module-design)
- [How to Write Module Motivation](#how-to-write-module-motivation)
- [How to Check Whether Method is Easy to Understand](#how-to-check-whether-method-is-easy-to-understand)
- [Method Section Skeleton](#method-section-skeleton)
- [Overview Subsection](#overview-subsection)
- [Section 3.1 and Other Module Subsections](#section-31-and-other-module-subsections)
- [Module Writing Pattern (Mermaid)](#module-writing-pattern-mermaid)
- [Implementation Details](#implementation-details)
- [Example Bank](#example-bank)


## Goal

Write the Method section clearly by following this sequence:

1. Answer key method-design questions.
2. Draw a pipeline figure sketch.
3. Write the method section step by step.

## Pre-Writing Questions

`Before writing Method, first answer: (1) what modules exist in the method, and (2) for each module, what is the workflow, why this module is needed, and why this module works.`

Recommended organization:

1. List all modules in the pipeline.
2. For each module, answer three questions:

- How does the module run?
- Why do we need this module?
- Why does this module work?

3. Organize answers as a mind map or a table for clarity.

## Method Writing Steps

`Method writing steps: (1) draw pipeline figure sketch, (2) map subsections from the sketch, (3) plan each subsection with motivation/design/advantages, (4) write module design first, (5) then add motivation and technical advantages.`

Step-by-step workflow:

1. Draw the pipeline figure sketch.
2. Use the sketch to organize Method subsection structure.
3. For each subsection, plan three parts: motivation, module design, and technical advantages.
4. Write module design first to build a concrete backbone.
5. Add motivation and technical advantages afterward.

## Three Elements of a Pipeline Module

`A pipeline module has three elements: Module design, Motivation of this module, and Technical advantages of this module.`

### 1) Module Design

Definition:

1. Describe representation/network/data-structure details.
2. Describe the forward process clearly: given input -> step 1 -> step 2 -> step 3 -> output.

### 2) Motivation of This Module

Definition:

1. Explain why this module is needed.
2. Use problem-driven logic: because problem X exists, we design module Y.

### 3) Technical Advantages of This Module

Definition:

1. Explain why this module has technical advantage over alternatives.
2. Tie advantage to measurable behavior when possible.

### Example of the Three Elements

Local cite:

1. `references/examples/method/example-of-the-three-elements.md`

## Method Content Decomposition

```mermaid
flowchart LR
    A["Draw the technical pipeline figure"] --> B["Decompose Method content"]
    B --> C1["Subsection 1 (Technical Module 1)"]
    B --> C2["Subsection 2 (Technical Module 2)"]
    B --> C3["Subsection 3 (Technical Module 3)"]
    C1 --> D1["Motivation"]
    C1 --> D2["Detailed design"]
    C1 --> D3["Technical advantage"]
```

## How to Write Module Design

`Module design usually has two parts: (1) describe specific data/network structures, and (2) describe forward process as input -> steps -> output.`

Writing structure:

1. Define key structures first (representation, network, data structure).
2. Write forward process in strict execution order.
3. End with output interpretation or purpose.

Sentence skeleton:

1. `We represent ... with ...`
2. `Given [input], we first ... then ... finally ...`
3. `This produces [output], which is used for ...`

Local cite:

1. `references/examples/method/module-design-instant-ngp.md`

## How to Write Module Motivation

`Module motivation is usually problem-driven: because a problem exists, we design xx to solve it.`

Typical opening sentences:

1. `A remaining problem/challenge is ...`
2. `However, we ...`
3. `Previous methods have difficulty in ...`

Local cite:

1. `references/examples/method/module-motivation-patterns.md`

## How to Check Whether Method is Easy to Understand

`Check method clarity from three levels: writing logic, paragraph writing, and sentence writing.`

### 1) Logic-level check

1. After finishing the paper, summarize the Method writing logic again.
2. Check whether this summarized logic is smooth and easy to follow.

### 2) Paragraph-level check

1. The first sentence of each paragraph should make readers immediately understand what this paragraph is about.
2. One paragraph should clearly deliver one message.

### 3) Sentence-level check

1. Carefully check whether the **motivation** of each sentence is explicit. Keep one thing clear to readers at all times: **why this sentence content is needed**.
2. Carefully check sentence-to-sentence flow.
3. Carefully check term consistency and avoid changing key terms back and forth.

## Method Section Skeleton

```latex
\section{Method}
% Overview
% Section 3.1
% Section 3.2
% Section 3.3
```

Local cite:

1. `references/examples/method/section-skeleton.md`

## Overview Subsection

`Overview should usually include: setting, core contribution, optional pipeline figure pointer, and a map of what each subsection contains.`

Writing structure:

1. One to two sentences for task setting.
2. One to two sentences for core contribution.
3. If pipeline/framework is novel, point to overview figure.
4. Tell readers what Section 3.1/3.2/3.3 covers.

Local cite:

1. `references/examples/method/overview-template.md`

## Section 3.1 and Other Module Subsections

`Basic subsection logic: (1) motivation of this module, (2) module forward process/module design, (3) technical advantages of this module.`

Local cite:

1. `references/examples/method/example-of-the-three-elements.md`

## Module Writing Pattern (Mermaid)

```mermaid
flowchart TB
    M1["State module motivation (challenge)"] --> M2["Define module design (representation/network)"]
    M2 --> M3["Describe forward process (input -> steps -> output)"]
    M3 --> M4["Explain technical advantages and verifiable gains"]
```

## Implementation Details

`Implementation details include hyperparameters (e.g., layer count, feature dimensions), coordinate transforms/normalization, and other practical details. Put them near the end of Method or in a dedicated Implementation Details section.`

## Example Bank

1. `references/examples/method-examples.md`
2. `references/examples/method/pre-writing-questions.md`
3. `references/examples/method/module-triad-neural-body.md`
4. `references/examples/method/module-design-instant-ngp.md`
5. `references/examples/method/module-motivation-patterns.md`
6. `references/examples/method/section-skeleton.md`
7. `references/examples/method/overview-template.md`
8. `references/examples/method/example-of-the-three-elements.md`
9. `references/examples/method/method-writing-common-issues-note.md`

# Nature Communications 2025 — Empirical Drafting Patterns (CS/AI corpus)

Use this file when drafting or restructuring a manuscript and you want
**genre-aware, evidence-backed structure calibration** beyond the generic
section fragments. The patterns below are distilled from a 2025 reading set of
20 open-access *Nature Communications* articles in computer science / AI
(research articles plus Perspective, Comment, Review, and benchmark/framework
papers). **Do not copy their wording.** Use the patterns to decide structure,
move order, and signal words; the short quoted fragments are pattern markers,
not text to reuse.

> Companion of `references/article-architecture.md` (generic move orders) and
> `nature-polishing/references/published-article-patterns.md`. This file adds
> the 2025 CS/AI evidence layer, quantified word preferences, and genre splits.

## 0. Decide the genre first — it picks the skeleton

| Genre | Skeleton |
|---|---|
| Research article | Abstract funnel → Intro (hook→gap→`Here we`) → Results (conclusion-first) → Discussion → Methods |
| Benchmark / framework | Same, but the *gap is "the field has no agreed standard"*; tables dominate; stress community / reproducibility / versioning |
| Review | Trend declaration → `This Perspective/Review explores…` → topic/modality chapters synthesising others' work → `Conclusions and outlook` |
| Perspective | History/era hook → numbered argument points → normative `X should…` advice → roadmap close |
| Comment | First-person singular, rhetorical question opening, analogy/history, no IMRaD, no abstract/figures |

State the detected genre before drafting; the rest of this file assumes a
research article unless noted.

## 1. Title

- Four recurring shapes, chosen by intent:
  - Noun phrase, method-led (most common): *AlphaFold prediction of structural ensembles of disordered proteins*
  - Declarative claim (the selling point is a finding): *Dendrites endow artificial neural networks with accurate, robust and parameter-efficient learning*
  - `System name: function` colon form (brands a tool/model): *CodonTransformer: a multispecies codon optimizer…*
  - Gerund/question for benchmark or Perspective: *Benchmarking large language models for…*; *Does provable absence of barren plateaus imply classical simulability?*
- An evaluative adjective often pre-loads the claim: *robust*, *generalizable*, *data-driven*.
- Almost never contains a number or a result; keep digits for the abstract.
- Prepositional chain carries "what + how + where": *…discovery and engineering **with** deep learning **using** CataPro*.

## 2. Abstract — the funnel

Five moves, one paragraph, 4–11 sentences (research longer, benchmark/active-learning tighter):

1. Field value / why-it-matters (present tense, often subject-less assertion)
2. Gap, almost always opened by **However** + a nominalised pain point
3. Hinge sentence: `Here we show/present/introduce X (FULL NAME, abbr.), a … that …`
4. One hard quantified result (a factor, %, or accuracy), past tense
5. Significance + optional resource link (GitHub)

Pattern markers: gap *"However, DE can be inefficient when mutations exhibit … epistatic behavior."*; hinge *"Here, we show that traditional fine-tuning outperforms zero- or few-shot LLMs in most tasks."*; close *"Our findings suggest…"* / *"These results indicate…"*.

## 3. Introduction

- **Hook**, three forms: importance declaration (*"The biological brain is remarkable in its ability to…"*); definition framing (*"Protein engineering is an optimization problem, where…"*); domain-then-obstacle (benchmark default: broad use → *"Despite its promises, progress … is impeded due to the absence of … benchmarks."*).
- **Gap** signal words cluster tightly: **However / remains / Unfortunately / underexplored / the scarcity of … hinder / Without X, Y cannot be …**. High-end move: quantify the scarcity — *"merely 124 (3.0%) have … structures in the PDB."*
- **Contribution**: `Here we…` / `In this work, we…`, usually with a `(Fig. 1)` pointer; multiple contributions as `First… Second… Finally…`.
- Make the **choice of system/problem explicit** — *"We chose this model system because…"* — this satisfies the "科学问题要科学" expectation: the question must be motivated, not assumed.

## 4. Results narrative

- **Subheadings** are either a conclusion sentence or a noun/gerund phrase naming the method — *"CodonTransformer generates DNA sequences with natural-like distributions"*, *"Exploring the biocatalytic synthesis landscape of McbA"*. Avoid neutral *Experiment 1 / Dataset* labels.
- **Conclusion-first**: the paragraph opens with the judgement, evidence and figure call follow — *"Interestingly, wt-McbA displayed a tolerance to multiple 'unprotected' functional groups…"*
- **Figure callouts**, two shapes: figure-led (*"Figure 3 (a) depicts the action distributions…"*) and trailing parenthetical (*"…synthesize 11 pharmaceutical compounds (Fig. 2C)"*).
- **Numbers** come as absolute + relative + direction — *"from 323.4 to 297.3 … representing an improvement of 8.8%"*; closing roll-up *"These findings collectively affirm that…"*.
- Paragraph-advance engine: `With [previous result], we next …` / `To <goal>, we <did> (Fig. X).`

## 5. Transitions (observed frequencies, 5-article subset)

`However` 51 ≫ `Furthermore` 22 · `Therefore` 19 · `Overall`/`Notably` 16 · `In addition` 13 · `In contrast` 6 · `Moreover` 4.
- **However** is the workhorse for turning, gap-opening, and surprise.
- Prefer **Furthermore** over **Moreover** for addition (22 vs 4).
- `Notably / Importantly / Interestingly / Surprisingly` flag the key finding; `Overall / In summary` close a block.

## 6. Syntax & register

- Tense: background/properties = present; what-we-did = past; current meaning/figure description = present.
- Voice: active **we** for narrative and claims; passive for apparatus/method (*"The optical convolutional layer is implemented by integrating…"*).
- Hedge (`may / suggest / likely / potential`) only in meaning sentences; boosters are rationed to the key finding.

## 7. Genre-difference cheatsheet

| Axis | Research | Review | Perspective | Comment |
|---|---|---|---|---|
| Data | own figures/numbers | synthesis of others' citations | argument, no experiments | none |
| Person | `we` + passive | `we` + survey | `we/our` throughout | first-person `I` |
| Stance | assert findings | weigh + outlook | argue + normative `should` | rhetorical, value-driven |
| Close | Discussion + limits | `Conclusions and outlook` + governance call | roadmap / conditions | call to action |

## 8. 中文迁移要点

- 保留信息链:`现象（现在时）→ 然而/目前仍/尚不清楚 → 本文提出 X → 带一个硬核数字的结果 → 意义升华`。
- 标题按体裁切模板:方法文用名词短语、卖点文用陈述句、工具用"系统名:功能"、论辩文可用疑问句;**标题不放数字与结论**。
- gap 必带信号词(然而/不幸的是/仍是挑战/鲜有研究/缺乏);高级写法用数字量化稀缺。
- 贡献句显式给出选题理由("之所以选该体系,是因为…"),呼应"科学问题要科学"。
- 对冲词(可能/提示/很可能)只用于意义句;少用"显著"——对应英文 `significantly` 在本语料 0 次,改用"明显/大幅/相当"(notably/substantially/considerably)。

# Nature Summary Paragraph Guide

## Contents

- [What this reference is for](#what-this-reference-is-for)
- [Core principle](#core-principle)
- [Canonical sentence-level structure](#canonical-sentence-level-structure)
- [Word-count and compression principle](#word-count-and-compression-principle)
- [How to read the annotated example in the image](#how-to-read-the-annotated-example-in-the-image)
- [Practical writing rules for this skill](#practical-writing-rules-for-this-skill)
- [Frequent failure modes](#frequent-failure-modes)
- [Relationship to other references in this skill](#relationship-to-other-references-in-this-skill)


## What this reference is for

This file distills the widely circulated annotated `Nature` example on how to construct a summary paragraph for a broad-audience paper. In `Nature`-style journals, this "summary paragraph" usually refers to the abstract-like opening summary that must let a non-specialist reader understand:

1. the field context,
2. the specific problem,
3. what this study shows,
4. why the result matters now,
5. and how far the claim should be generalized.

Use this reference when:

1. the target journal is `Nature` or a close Nature-family venue,
2. the user is drafting or rebuilding an abstract / summary paragraph,
3. the user asks for a broad-audience opening paragraph,
4. the draft has results but lacks cross-disciplinary readability.

## Core principle

A strong `Nature` summary paragraph is not just a compressed abstract. It is a tightly staged reader funnel:

1. start broad enough for scientists outside the subfield,
2. narrow to the exact unresolved problem,
3. state the main finding early and explicitly,
4. spend several sentences interpreting what the result changes,
5. end by widening back out to the broader scientific or practical context.

In short:

`broad field -> sharper background -> exact problem -> here we show -> what the result changes -> broader context / outlook`

## Canonical sentence-level structure

The annotated example in the image implies the following sentence jobs.

### 1. Broad field introduction (1-2 sentences)

Goal:

1. orient any scientist, not just an expert,
2. establish why the field/problem area matters,
3. avoid dense terminology too early.

Rule:

1. If a reader from another discipline cannot follow the first 1-2 sentences, the paragraph is too specialized too early.

### 2. More detailed background (2-3 sentences)

Goal:

1. move from field-scale context to the specific system/process/problem,
2. introduce the minimum specialist concepts needed to understand the study,
3. prepare the unresolved issue naturally.

Rule:

1. This layer may use subfield terminology, but each term must feel motivated by the sentence before it.
2. Do not dump mechanism details here; only include what the reader needs to understand the problem.

### 3. General problem statement (1 sentence)

Goal:

1. name the exact unresolved problem addressed by this study,
2. create the hinge between background and contribution.

Rule:

1. This sentence should be unmistakable.
2. It usually has the form `However, ... remains unknown`, `Yet whether ... is unclear`, or an equivalent unresolved-gap statement.

### 4. Main result sentence (1 sentence)

Goal:

1. state the paper's central finding clearly,
2. make the reader feel the paper has now "arrived".

Rule:

1. Use `Here we show`, `Here we demonstrate`, or a discipline-appropriate equivalent when the evidence is strong enough.
2. This sentence should express the main claim, not the whole method pipeline.

### 5. Direct implications of the result (2-3 sentences)

Goal:

1. explain what the main result reveals,
2. compare it with what was previously believed or assumed,
3. show how the result adds to prior knowledge.

Rule:

1. This is usually the intellectual center of the paragraph.
2. Do not merely list more results; interpret the main result.
3. If there are multiple supporting findings, arrange them so each one strengthens the same message.

### 6. More general context (1-2 sentences)

Goal:

1. place the result back into a broader biological, physical, methodological, or translational context,
2. show why the result matters beyond the immediate experiment.

Rule:

1. This expansion must still be anchored in what the study actually supports.
2. Avoid hype that leaps beyond the evidence.

### 7. Optional broader perspective (2-3 sentences)

Goal:

1. provide a final wider perspective for a non-specialist reader,
2. connect the work to future models, applications, or downstream relevance.

Rule:

1. This section is optional and depends on editor tolerance for length and on whether accessibility truly improves.
2. The example notes that under these conditions the paragraph may extend toward ~300 words.
3. If included, the final perspective should feel earned by the prior evidence, not appended as a generic impact slogan.

## Word-count and compression principle

The image example implies a practical compression rule:

1. the paragraph can be around ~190 words without the final broader-perspective section,
2. and around ~250 words with that section,
3. while still preserving the staged logic above.

This means compression should happen by:

1. removing repeated background,
2. collapsing redundant result statements,
3. keeping only the one or two most decision-relevant implications,

not by deleting the problem sentence or the `here we show` hinge.

## How to read the annotated example in the image

The example paragraph progresses in a very deliberate order.

### Segment A — broad introduction

1. `During cell division, mitotic spindles are assembled by microtubule-based motor proteins.`
2. `The bipolar organization of spindles is essential for proper segregation of chromosomes ...`

What these lines do:

1. They establish a broad cell-biology setting understandable to many scientists.
2. They explain why the system matters before discussing the specific protein family.

### Segment B — more detailed background

1. The paragraph then introduces plus-end-directed homotetrameric motor proteins of the kinesin-5 (`BimC`) family.
2. It also names an existing conceptual model, the `push-pull mitotic muscle` model, in which kinesin-5 and opposing motors act between overlapping microtubules.

What these lines do:

1. They narrow from general spindle function to the specific mechanistic actors.
2. They provide enough conceptual scaffolding for the reader to understand the unresolved issue.

### Segment C — exact unresolved problem

1. `However, the precise roles of kinesin-5 during this process are unknown.`

What this line does:

1. It is the hinge sentence.
2. It states the exact knowledge gap in one unmistakable move.

### Segment D — main finding

1. `Here we show that the vertebrate kinesin-5 Eg5 drives the sliding of microtubules depending on their relative orientation.`

What this line does:

1. It states the central claim directly.
2. It uses the canonical `Here we show` signal to mark the paper's main advance.

### Segment E — direct implications and supporting findings

1. The following sentences explain that, in controlled `in vitro` assays, `Eg5` can move simultaneously toward the plus ends of both microtubules it crosslinks.
2. They then infer that anti-parallel microtubules undergo relative sliding at rates comparable to spindle pole separation `in vivo`.
3. They add that `Eg5` can tether microtubule plus-ends, suggesting an additional microtubule-binding mode.
4. The authors then synthesize these findings into a mechanistic interpretation of how kinesin-5 family members may function in mitosis.

What these lines do:

1. They do not merely pile up facts.
2. They show what the main result reveals about spindle organization and motor function.
3. They connect observations to a revised mechanistic understanding.

### Segment F — broader context and outlook

1. The paragraph then says the assay may serve as a starting point for more sophisticated `in vitro` spindle models.
2. It gives an example: testing the individual and combined action of multiple mitotic motors.
3. It closes by linking `Eg5` inhibition to anti-cancer drug development and arguing that a quantitative assay for motor function is relevant to that development.

What these lines do:

1. They widen from the specific finding to broader methodological and translational significance.
2. They remain concrete, rather than ending with vague claims about importance.

## Practical writing rules for this skill

When drafting a `Nature` summary paragraph:

1. make the first two sentences survivable for a cross-disciplinary scientist,
2. reserve the exact unresolved problem for one explicit hinge sentence,
3. ensure the main result arrives no later than the middle of the paragraph,
4. spend more space interpreting the result than naming method details,
5. end with bounded significance, not slogan-like impact,
6. if quantitative support exists, attach it to the strongest result sentence cluster,
7. if the draft begins with `Here we show ...`, verify that enough field context appears before it.

## Frequent failure modes

### Failure mode 1 — opening too narrow

1. Starts with gene/protein/material/model names before any field context.
2. Non-specialists cannot tell why the study matters.

### Failure mode 2 — no clear gap sentence

1. Background slides directly into contribution.
2. Readers cannot identify the exact unresolved problem.

### Failure mode 3 — `Here we show` comes too early or too late

1. Too early: the reader lacks enough setup.
2. Too late: the paragraph feels like an introduction review rather than a summary paragraph.

### Failure mode 4 — result listing without interpretation

1. Several findings are listed sequentially.
2. The paragraph never explains what they collectively change.

### Failure mode 5 — overextended final significance

1. The ending jumps to societal or clinical importance unsupported by the evidence.
2. The paragraph sounds inflated rather than authoritative.

## Relationship to other references in this skill

1. Use this file together with `references/abstract.md` when the user is drafting an abstract for a broad-audience Nature-family venue.
2. Use `static/fragments/journal/nature.md` for journal-level constraints such as audience and claim calibration.
3. Use `static/fragments/section/abstract.md` for the compact default abstract movement.
4. Use this file when the user specifically needs the stronger `Nature summary paragraph` logic rather than a generic abstract template.

# Paper Review

## Goal

Use an adversarial, reviewer-style checklist to detect reject risks early and revise the paper before submission.

## Core Principle

Pursue perfectionism in paper quality: assume reviewers will probe every weak point and proactively fix them.

## Critical Rule (Do Not Violate)

Every major claim, especially in Abstract and Introduction, must be:

1. technically correct, and
2. explicitly supported by experimental evidence.

If a claim is not supported, either add evidence or weaken/remove the claim.

## What Usually Gets a Paper Accepted

1. Sufficient contribution (for example: novel task, novel pipeline, novel module, novel design choices, new experimental findings, or new insight).
2. Better empirical performance than prior methods under fair comparisons.
3. Sufficient comparison experiments and ablation studies.

## Common Rejection Dimensions

| Rejection Dimension          | Typical Failure Signals                                                                                                                                                                                                                                                                    |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1. Insufficient contribution | 1.1 Targeted failure cases are too common.<br /> 1.2 Proposed technique is already well explored; expected gains are predictable/well-known.                                                                                                                                               |
| 2. Unclear writing           | 2.1 Missing technical details; work is not reproducible.<br />2.2 A method module lacks clear motivation.                                                                                                                                                                                  |
| 3. Weak empirical effect     | 3.1 Improvement over prior methods is only marginal.<br /> 3.2 Even if better than previous methods, absolute performance is still not strong enough.                                                                                                                                      |
| 4. Incomplete evaluation     | 4.1 Missing ablation studies.<br />4.2 Missing important baselines or important evaluation metrics.<br /> 4.3 Datasets are too simple to prove the method truly works.                                                                                                                    |
| 5. Problematic method design | 5.1 Experimental setting is unrealistic.<br />5.2 Method has technical flaws and appears unreasonable.<br />5.3 Method is not robust and needs per-scenario hyperparameter tuning. <br /> 5.4 New design introduces stronger limitations than its benefits, leading to negative net value. |

## End-of-Paper Self-Review Question List

Add this checklist near the end of the draft while revising.
Use each question to trigger concrete edits before submission.

### 1. Contribution

1. What new knowledge does this paper give to readers?
2. Are we solving a truly meaningful failure case, not a trivial/common one?
3. Is the technical idea genuinely non-obvious beyond well-explored practice?
4. Is our gain surprising or insightful rather than a predictable improvement?
5. Is there at least one clear novelty type (task/pipeline/module/design finding/insight)?

### 2. Writing Clarity

1. Can a knowledgeable reader reproduce the method from the paper?
2. Did we provide enough technical detail for each key module?
3. Is the motivation of every module explicit and logically connected to a challenge?
4. Are terms and notation consistent across sections?
5. Does each paragraph carry one clear message with smooth transitions?

### 3. Experimental Strength

1. Are improvements over strong baselines meaningful, not just statistically tiny?
2. Is absolute performance competitive enough for the target venue?
3. Are gains consistent across multiple datasets/settings/metrics?
4. Do we report both strengths and failure cases honestly?

### 4. Evaluation Completeness

1. Do we include ablations for all key design choices?
2. Are all strong/recent baselines included under fair settings?
3. Are evaluation metrics standard and sufficient for this task?
4. Are datasets/scenarios challenging enough to validate real effectiveness?
5. Are comparison and ablation protocols clearly documented?

### 5. Method Design Soundness

1. Is the experimental setting realistic for practical use?
2. Does the method have hidden technical defects or unreasonable assumptions?
3. Is the method robust without heavy per-case hyperparameter retuning?
4. Do benefits outweigh added complexity and new limitations?
5. Could reviewers reasonably argue that the net benefit is negative?

## Adversarial Writing Workflow

1. Read the paper as a skeptical reviewer.
2. Answer every question above with explicit evidence from the paper.
3. Mark each item as `pass`, `needs revision`, or `needs new experiment`.
4. Revise claims, writing, experiments, or method scope accordingly.
5. Repeat until no major rejection risk remains.

# Paragraph Flow

Use this reference when the user asks whether a paragraph flows, makes sense, or
is clear.

## Core principle

Flow is not decoration. A paragraph flows when an external reader can identify:

- the paragraph's single message
- how the first sentence announces that message
- how each following sentence relates to the previous one
- how the paragraph supports the section thesis

## Reader test

Read as a skeptical but fair external reader:

1. Does the paragraph have one explicit message?
2. Does the first sentence state what the paragraph is doing?
3. Are all key nouns, terms and abbreviations readable without hidden context?
4. Does each sentence connect by cause, contrast, consequence, refinement, or example?
5. Is any sentence carrying material that belongs in another paragraph?

## Reverse outlining

For a section-level flow check:

1. Write down the section thesis or main claim.
2. Write down each paragraph's topic sentence.
3. Write down the evidence or explanation under each paragraph.
4. Check `topic sentence -> section thesis`.
5. Check `evidence -> topic sentence`.
6. Revise or remove any paragraph that cannot be mapped cleanly.

If reverse outlining is hard, the section probably has a hidden structure problem.

## Repair moves

- Split paragraphs that contain two messages.
- Move definitions before terms are reused.
- Replace vague transitions with explicit relations such as `therefore`,
  `however`, `by contrast`, `for example`, or `as a result`.
- Add temporary subsection labels during revision, then remove labels that are
  not needed in the final manuscript.
- Keep paragraph openings claim-first unless the section needs a brief setup.

# Related Work Writing Guide

## Goal

Position your work against the most relevant lines of research, and make your novelty easy to verify.

## Workflow

1. List directly competing and recent baseline papers first.
2. Group literature by technical topic (not by publication year alone).
3. For each topic: summarize common paradigm, then key limitation relevant to your challenge.
4. End each topic by clarifying your distinction.

## Topic Design

Use 2-4 focused topics, for example:

1. Task-specific mainstream methods.
2. Methods closest to your core idea.
3. Auxiliary techniques your method builds on.

## Paragraph Template

1. Topic sentence: define scope of this topic.
2. Representative methods: one compact summary.
3. Limitation tied to your target technical challenge.
4. Transition sentence that leads to your method.

## Do and Don't

1. Do compare mechanisms, assumptions, and failure modes.
2. Do emphasize the exact gap your method fills.
3. Do not make Related Work a citation dump.
4. Do not hide strongest baselines.

## Checklist

1. Are all strongest/recent competitors covered?
2. Is each topic connected to your problem setting?
3. Is your difference explained in technical terms, not marketing terms?
4. Is citation coverage complete for all core claims?

# Initial submission package

Use this reference for first-submission materials before peer review. Journal instructions override these defaults.

## Contents

1. Intake and routing
2. Deliverable matrix
3. Initial cover letter
4. Title page
5. Highlights and editorial summary
6. Declarations
7. Reviewer suggestions
8. Completeness audit
9. LaTeX templates
10. Output format

## 1. Intake and routing

Collect or mark as missing:

- Target journal, article type, submission stage, manuscript title, short title,
  abstract, and keywords.
- Author names, order, affiliations, corresponding-author details, email, and ORCID.
- One-sentence claim, strongest evidence, novelty boundary, significance, and journal fit.
- Funding identifiers, acknowledgements, conflicts, ethics approvals, consent, and permissions.
- Data/code repository links, accession numbers, license, embargo, and access conditions.
- Preprint, conference version, related manuscripts, prior submission, or concurrent-submission facts.
- Suggested/opposed reviewers with affiliation, email, expertise, relationship/conflict check, and rationale.
- Journal-specific items such as highlights, graphical abstract, reporting summary, checklist, or author declaration.

Do not infer unknown administrative facts. Use `[AUTHOR_INPUT_NEEDED: ...]`.

## 2. Deliverable matrix

Return a compact table:

| Item | Status | Source or missing input | Draft/output |
|---|---|---|---|
| Main manuscript | required / optional / N/A | path or note | filename/status |
| Anonymous manuscript | required / optional / N/A | journal rule | filename/status |
| Title page | required / optional / N/A | author metadata | draft/status |
| Cover letter | required / optional / N/A | claim + fit | draft/status |
| Highlights | required / optional / N/A | key findings | draft/status |
| Graphical abstract | required / optional / N/A | route to nature-figure | status |
| Supplementary information | required / optional / N/A | supplied files | status |
| Reporting checklist | required / optional / N/A | study design | status |
| Declarations | required / optional / N/A | author facts | draft/status |
| Reviewer suggestions | required / optional / N/A | author candidates | draft/status |

## 3. Initial cover letter

This is not a revision cover letter.

Recommended anatomy:

```text
Dear [Editor name / Editors],

Please consider our manuscript, "[Title]," for publication as a [Article type] in [Journal].

[What the study addresses and the principal finding, in 1-2 sentences.]
[What is specifically new and which evidence supports it, in 1-2 sentences.]
[Why the result matters to this journal's readership, in 1 sentence.]

[Required declarations: originality, author approval, related manuscripts/preprint, conflicts, or other journal-specific statements.]

Thank you for your consideration.

Sincerely,
[Corresponding author]
[Affiliation and contact details]
```

Rules:

- First classify the cover letter as required, optional, or not accepted. Do not
  infer that every journal requires one.
- Usually 250-400 words unless the journal specifies otherwise.
- Do not repeat the abstract.
- Do not use unsupported priority claims such as "the first" or "unprecedented".
- Do not name-drop editors, reviewers, or famous researchers as persuasion.
- Do not claim journal fit without connecting the finding to the journal's scope and readers.

## 4. Title page

Draft or audit:

- Full title and short/running title.
- Author names in final order.
- Affiliation mapping and present addresses.
- Corresponding author(s), email, postal address when required, and ORCID.
- Equal-contribution and senior-author notes.
- Word count, figure/table count, keywords, and article type when required.
- Funding, acknowledgements, conflicts, data/code availability, ethics, consent, and author contributions when the journal places them on the title page.

For double-anonymous review, keep identifying details out of the anonymous manuscript.

## 5. Highlights and editorial summary

Highlights:

- Three to five bullets.
- One finding per bullet.
- Prefer concrete results over generic importance claims.
- Respect the journal's character limit.

Editorial summary or significance statement:

- Problem and audience.
- Main advance.
- Why the evidence changes understanding or practice.
- Scope and limitation.

## 6. Declarations

Prepare separate, fact-grounded blocks as applicable:

- CRediT author contributions.
- Competing interests.
- Funding.
- Acknowledgements.
- Data availability.
- Code availability.
- Ethics approval and consent to participate.
- Consent for publication.
- Materials availability.
- Preprint and related-manuscript disclosure.
- Originality and all-author approval.
- Third-party permissions.
- AI/LLM use disclosure when required by the journal and applicable to the work.

Never convert "available on request" into a public repository claim. Never invent contribution roles, grant numbers, approval IDs, accession numbers, or licenses.

## 7. Reviewer suggestions

When requested, return:

| Name | Institution | Email | Expertise fit | Conflict check | Rationale |
|---|---|---|---|---|---|

Require the author to confirm:

- No recent coauthorship, same institution, close collaboration, supervisory relationship, personal conflict, or other journal-defined conflict.
- Institutional email and current affiliation are accurate.
- The candidate has topic/method expertise relevant to the manuscript.

For opposed reviewers, give a short factual reason without attacking competence or character.

## 8. Completeness audit

Check:

- Journal instructions and article type are confirmed.
- All author names, order, affiliations, and corresponding-author details match every file.
- Title, abstract, keywords, declarations, repository links, and manuscript metadata are consistent.
- Anonymous and identified files are separated correctly.
- Figures, tables, supplements, permissions, and checklists are present and cited.
- Initial-submission and accepted-in-principle requirements have not been
  conflated.
- Data/code statements point to real destinations and access conditions.
- Cover letter matches the manuscript's actual claims and does not overstate novelty.
- Suggested reviewers pass conflict checks.
- Required placeholders are resolved.
- Related manuscripts that the journal requires for assessment are attached as
  clearly marked separate files, not only named in the cover letter.

Readiness:

- `ready`: all required facts and files are present and cross-checked.
- `ready_with_author_checks`: drafts are complete but administrative facts need confirmation.
- `blocked`: required ethics, authorship, permissions, integrity, or journal-rule information is missing.

## 9. LaTeX templates

Use these only for initial submission:

| Template | Purpose |
|---|---|
| `templates/submission/initial-cover-letter.tex` | Initial editor-facing cover letter |
| `templates/submission/title-page.tex` | Identified title page and declarations |
| `templates/submission/highlights-and-summary.tex` | Highlights and editorial/significance summary |
| `templates/submission/declarations-and-reviewers.tex` | Submission declarations and reviewer suggestions |

When producing LaTeX:

- Copy only the requested templates into the user's delivery folder.
- Replace placeholders only with author-confirmed facts.
- Keep unresolved facts visibly marked as `AUTHOR_INPUT_NEEDED`.
- Check journal instructions before deciding which declarations belong on the title page or in separate files.
- Compile when a LaTeX engine is available and report any missing package or compilation error.
- Never reuse `nature-response/templates/cover-letter.tex`; that template is explicitly for a revised manuscript.

## 10. Output format

Return:

1. `Submission readiness:`
2. `Deliverable matrix:`
3. `Draft materials:` with clear headings for each requested item.
4. `AUTHOR_INPUT_NEEDED:` as a consolidated checklist.
5. `Cross-file consistency checks:`
6. `Next actions:` ordered by blocking priority.

---
name: nature-writing
description: Draft, restructure, or plan Nature-style manuscript sections and initial-submission materials from author-provided claims, results, figures, notes, or Chinese drafts. Use for abstracts, introductions, related work, methods, Results or experiments, discussions, conclusions, titles, full manuscript arguments, and first-submission packages such as cover letters, title pages, highlights, author contributions, availability or declaration text, and reviewer suggestions. Also use to classify Results evidence, decide what belongs in main text, captions, Methods or source data, or Supplementary Information, compress Results to the shortest sufficient evidence chain, prevent revision accretion, and audit paragraph necessity or claim repetition. Trigger on drafting a paper or section, structuring a manuscript, academic writing, first submission, 投稿材料、首次投稿、投稿信、标题页、亮点、作者贡献、数据可用性声明、推荐审稿人.
---

# Nature-Style Scientific Writing — Router

This skill is split into two layers:

- A **static layer** under `static/` that holds versioned, reusable content fragments (core stance + workflow, paper-type playbooks, per-section drafting guidance, initial-submission guidance, language-specific rules, per-journal style).
- A **dynamic layer** (this file plus `manifest.yaml`) that detects the request's axes and loads only the fragments needed for the current job.

Do not try to apply the drafting logic from memory or from this router. Always load fragments from disk as described below.

## Routing protocol

Follow these five steps every time the skill is invoked.

### 1. Load the manifest and the core layer

Read [manifest.yaml](manifest.yaml). It declares the axes (`task`, `paper_type`, `section`, `language`, `journal`), the allowed values, and the file paths each value maps to.

Also read every file listed under `always_load`. These hold the default stance, writing workflow, and output format that apply to every drafting job.

### 2. Detect the axis values for this request

For each axis in the manifest, decide the value using the manifest's `detect:` hint and the user's input:

- `task` — manuscript / submission-package. Use `submission-package` for first-submission materials, never for revision correspondence.
- `paper_type` — research / methods / hypothesis / algorithmic / review. Default: research.
- `section` — abstract / intro / related-work / method / experiments / discussion / conclusion / title. May be multiple. Ask the user if it is ambiguous and matters for the draft.
- `language` — en or zh-to-en. Detect from the user's notes themselves.
- `journal` — nature / nature-family / nat-comms / nat-mach-intell / generic.
  Default: generic. Use `nature` only for the flagship journal Nature,
  `nat-comms` for Nature Communications, `nat-mach-intell` for Nature Machine
  Intelligence (NMI), and `nature-family` for other Nature Portfolio titles or
  an unspecified Nature-family request.

State the detected axis values in one short line to the user before drafting, so they can correct you cheaply.

### 3. Load the matching fragments

For each axis value, Read the file mapped in the manifest. Skip the `section` axis when the task is `submission-package` or when the user explicitly asks for a free-floating argument paragraph with no section context.

Do **not** read every fragment in `static/`. Load only what step 2 selected.

### 4. Draft using the loaded material

Apply the loaded fragments in this priority order:

1. Core stance + intake (`core/stance.md`) — surface missing claim / evidence / boundary before drafting.
2. Paper-type playbook — argument chain, drafting order.
3. Section-specific drafting rules and structure.
4. Task-specific submission rules when `task=submission-package`.
5. Journal-specific framing and constraints.
6. Language-specific sentence and paragraph rules (apply last).

For `task=manuscript`, run the workflow in `core/workflow.md` end-to-end. Do not skip planning just because the user asked for prose immediately.

When drafting or restructuring Results, or compressing a full manuscript's main
text, also load `../nature-shared/core/main-text-discipline.md` before building
the paragraph map. Classify every result by function, allocate it across main
text, captions, Methods/source data, and SI, then draft the shortest sufficient
evidence chain. Do not equate a complete analysis record with a complete main
text.

When the target is flagship Nature, Nature Communications, Nature Machine
Intelligence, or another Nature Portfolio title, load the matching shared
Nature-style corpus guidance for the section being drafted:

- Results or Discussion →
  `../nature-shared/core/nature-results-discussion.md`
- Introduction or whole-manuscript narrative →
  `../nature-shared/core/nature-introduction.md`
- Abstract → `../nature-shared/core/nature-abstract.md`

Use these files for claim escalation, question-chain alignment,
discovery-centred compression, and synthesis. They were initially distilled
from published NMI papers and generalized as Nature-style defaults; do not
present them as official policy, and let the target journal's current rules
override them.

For any Discussion drafting, restructuring, or section audit, also load
`../nature-shared/core/discussion-argument-language.md`. Use it to select the
opening anchor, control the reverse-funnel expansion, distinguish literature
positioning from citation decoration, calibrate modal strength to evidence,
and turn limitations and future work into claim-specific reasoning. This is
general writing guidance rather than an official journal rule.

For `task=submission-package`, follow `static/fragments/task/submission-package.md` and `references/submission-package.md` instead. Build the deliverable matrix and readiness audit; do not force manuscript paragraph architecture onto administrative submission materials.

If essential evidence or boundary is missing, write a placeholder and list it under `Assumptions or missing inputs:` instead of inventing content.

### 5. Reach for references only when needed

The files under `references/` are deep references and the example library, not defaults. Open them on demand per the `references.on_demand` table in the manifest. Typical triggers:

- The user asks for a concrete example or template → `references/examples/index.md`.
- A section's draft has structural problems that the section fragment alone does not explain → the matching `references/<section>.md`.
- The user needs a broad-audience `Nature` abstract opening or asks about a `summary paragraph` → `references/nature-summary-paragraph.md`.
- The user asks "does this paragraph flow?" → `references/paragraph-flow.md`.
- The user asks for a self-review or rejection-risk audit → `references/paper-review.md`.
- The user asks what belongs in the main text, captions, or SI; wants a shorter
  Results section; or is adding reviewer-driven explanation →
  `../nature-shared/core/main-text-discipline.md`.
- The user requests a complete first-submission package, templates, or a submission-readiness audit → `references/submission-package.md`.
- The target is the flagship journal Nature and exact submission or formatting
  requirements matter → `../nature-shared/journal-formats/nature.md`.
- The target is Nature Machine Intelligence and exact content-type, submission,
  data/code or production requirements matter →
  `../nature-shared/journal-formats/nature-machine-intelligence.md`.
- Any Nature / Nature Portfolio target needs Results claim progression,
  evidence-bound interpretation, robustness placement, or Discussion synthesis
  → `../nature-shared/core/nature-results-discussion.md`.
- Any target needs a Discussion function chain, evidence-calibrated modal
  language, claim-specific limitations, non-redundant literature positioning,
  or uncertainty-driven future work →
  `../nature-shared/core/discussion-argument-language.md`.
- Any Nature / Nature Portfolio target needs an Introduction funnel, exact gap,
  literature logic, question-first novelty, study roadmap, or alignment with
  Results → `../nature-shared/core/nature-introduction.md`.
- Any Nature / Nature Portfolio target needs abstract evidence-chain,
  main/supporting-claim, numeric-result, or final-payoff decisions →
  `../nature-shared/core/nature-abstract.md`.
- The work involves regulated or specialist research compliance →
  `../nature-shared/core/research-compliance.md`.

## Submission boundary

- `nature-writing` owns **initial submission** materials prepared before peer review.
- `nature-response` owns revision cover letters, rebuttals, point-by-point responses, marked manuscripts, appeals, and other post-decision correspondence.
- Route graphical abstracts and TOC graphics to `nature-figure`; route simulated pre-submission peer review to `nature-reviewer`.

## Why this split

- The static layer is versioned and reviewable. Adding a new journal style, paper type, or section is one new file plus one manifest line.
- The dynamic layer keeps each invocation cheap: only the fragments relevant to this draft enter context, instead of the full multi-thousand-line reference set.
- The router itself is short on purpose. Update fragments, not this file, when adding scope.
- This structure mirrors `nature-polishing` so shared content can later be lifted into a `nature-shared/` layer used by both skills.

# Output format (writing)

Default output:

1. `Draft:` — the requested prose.
2. `Section outline:` — `3-7` compact bullets when the task involves a full section.
3. `Assumptions or missing inputs:` — only material issues; do not pad with style nits.
4. `Claim-evidence map:` — for major claims, in the form:
   `Claim: ... | Evidence: ... | Status: supported / needs evidence / inferred`
5. `Why this structure:` — `2-4` short bullets on the structural choices made.
6. `To redirect me:` — one line inviting targeted feedback, e.g. "Name the paragraph or claim that is off and I will revise only that, keeping the rest." This sets up the targeted revision loop (workflow step 9) instead of a full rewrite.

For Chinese-author notes, provide polished English first, then brief Chinese notes explaining major structural choices.

For a Results or full-main-text restructuring task, also include a compact
`Main-text discipline audit:` after the prose:

- result allocation: core / necessary support / qualification / SI-bound detail
- relocated, replaced, compressed, or deleted material
- primary statistic retained in the main text and secondary analyses routed to SI
- before/after word count for each revised subsection

Return the full allocation and claim-repetition tables only when the manuscript
is being comprehensively restructured or the user asks for the audit trail.

If essential evidence or boundary is missing, do not invent. Write a placeholder such as `[Evidence needed: comparator group accuracy on test set X]` and list it under `Assumptions or missing inputs:`.

For `task=submission-package`, replace the default manuscript format with:

1. `Submission readiness:`
2. `Deliverable matrix:`
3. `Draft materials:`
4. `AUTHOR_INPUT_NEEDED:`
5. `Cross-file consistency checks:`
6. `Next actions:`

# Default stance (writing)

## Author evidence comes first

- Do not invent results, mechanisms, references, methods, novelty, sample sizes, statistics, or limitations.
- Write the argument before writing the sentences.
- Prefer confirming over guessing. If essential input is missing or the framing is ambiguous, do not silently draft a full section on an assumed premise — confirm first (see Intake below) instead of filling the gap.

## Reader workflow

See `../../../nature-shared/core/reader-workflow.md` (loaded via manifest `always_load`) for the 5-step reader question sequence. Draft and revise so the paper answers those questions in order.

## Claim discipline

- Use ambitious but bounded claims.
- Calibrate verbs: `show`, `demonstrate`, `suggest`, `indicate`, `enable`, `may`, `could`.
- Remove unsupported novelty and universal claims (`first ever`, `unprecedented`, `revolutionary`) unless the evidence genuinely supports them.

## Intake — required inputs before drafting

Identify before writing:

- **manuscript section**: title, abstract, introduction, related-work, method, results/experiments, discussion, conclusion, significance paragraph, or full outline
- **paper type**: research / methods / hypothesis / algorithmic / review (see paper_type fragment)
- **core claim**: what the paper actually demonstrates
- **evidence**: figures, measurements, comparisons, datasets, statistics, or examples
- **boundary**: where the claim stops
- **target journal or word limit** if provided
- **terminology**: on first contact with the material, extract the recurring methods, models, datasets, metrics, abbreviations, and notation into a Terminology Ledger and reuse the canonical forms across every section (see `../../../nature-shared/core/terminology-ledger.md`)

If any of `core claim`, `evidence`, or `boundary` is absent, or the framing is ambiguous, run the **confirmation gate** in `workflow.md` (step 3b) before drafting the full section: echo back your one-sentence argument and key assumptions, ask at most 2–3 targeted questions, and wait for the user. A wrong assumed premise surfaced only in the final notes wastes the entire draft. If the user prefers to proceed without answering, you may still produce a scaffold with explicit placeholders.

# Writing workflow

Run these steps for any drafting or restructuring task. Steps 1-3 are planning, step 3b is an alignment gate, 4-6 are drafting, 7-8 are checking, step 9 is the revision loop.

## 1. Build a one-sentence argument

> In [system/problem], we show [advance] using [approach], supported by [evidence], with [boundary].

Force every section to serve this sentence. If the sentence cannot be written, the paper does not yet have an argument — surface that to the user.

## 1b. Build the Terminology Ledger

On first contact with the material, extract the recurring terms, abbreviations, notation, and proper names into a Terminology Ledger before drafting any prose. Lock the canonical forms and reuse them across every section. See `../../../nature-shared/core/terminology-ledger.md`.

## 2. Choose section architecture

Pick the section structure from the relevant `section/*.md` fragment and, if needed, deeper patterns from `references/article-architecture.md`.

## 3. Map each paragraph to one job

Each paragraph must do exactly one job from: context, gap, approach, result, comparison, mechanism, implication, limitation.

If a paragraph carries two jobs, split it before drafting.

## 3a. Allocate Results evidence before drafting

When the task includes Results, a full manuscript, main-text compression, or
main-versus-SI placement, load
`../../../nature-shared/core/main-text-discipline.md`. Classify each result as
core discovery, necessary support, qualification, robustness, heterogeneity,
provenance detail, alternative inference, or edge case. Build the shortest
sufficient main-text evidence chain and record the destination of everything
else. Do not bury conclusion-changing evidence in SI.

## 3b. Confirmation gate — align before drafting

Drafting a full section on a wrong assumed premise wastes the whole draft and is the main reason output "does not match what I meant". Before writing full prose, show the user a short alignment block and **stop for confirmation**:

- **One-sentence argument** (from step 1) — the single most important thing to get right. Echo it back in plain language.
- **Plan**: detected paper type, section(s), journal / word limit, and the paragraph map from step 3 as a short bullet list.
- **Key terminology**: the canonical forms locked in the Terminology Ledger (step 1b) for the main methods, models, datasets, and metrics. Surface them here so the user can fix a wrong canonical term before it propagates through every section.
- **Primary reader**: who the draft is optimized for, and which of the five reader questions it leads with (relevance / novelty / trust / reuse / meaning — see `../../../nature-shared/core/reader-workflow.md`). Getting the lead question wrong is a common silent cause of "this is not what I meant".
- **Key assumptions**: anything else you inferred rather than were told — especially what the core contribution is and which result to lead with. Mark each clearly as an assumption.
- **At most 2–3 targeted questions**, only on genuinely ambiguous, high-leverage points (how to frame the core contribution, target audience / journal, which result leads). Do not ask about things the user already made clear, and do not pad the list to reach three.

Then wait for the user to confirm or correct before drafting the full section.

Shortcuts:

- **Skip the gate** when the core claim, evidence, and boundary are all clearly given and there is no real ambiguity in framing. In that case just state the one-sentence argument in a single line (per the router) and proceed.
- **Depth dial**: for a full section or a major rewrite, offer to deliver the outline first (the paragraph map from step 3) and expand to full prose only after the user approves it. Reacting to an outline is far cheaper than reacting to full prose. Skip this for short or single-paragraph requests.
- **Style, not substance**: if the user says the voice or style "is not mine", do not keep guessing — ask for one short sample of their own writing, then calibrate to it. From the sample, match: typical sentence length and rhythm, hedging level (`demonstrate` vs `may` / `could`), preferred connectives and transitions, person (first-person `we` vs passive), and terminology / abbreviation choices. Match the voice, not the content — never reuse the sample's claims or facts.

## 4. Draft from evidence outward

Keep claims near the data that support them. Do not stack claims at the top of a section then leave evidence at the bottom.

## 5. Calibrate verbs to evidence strength

`show` / `demonstrate` need strong direct evidence. `suggest` / `indicate` are for trend-level or indirect evidence. `may` / `could` are for plausible but unverified mechanisms.

## 6. Remove unsupported novelty and universal claims

Sweep for `first`, `unique`, `unprecedented`, `comprehensive`, `complete`, `always`, `never`. Replace with bounded claims or delete.

## 7. Run a paragraph-flow check

- One paragraph, one message.
- The first sentence is the topic / claim.
- Each subsequent sentence has an explicit relation to the previous one (cause, comparison, restriction, example).

For full reverse-outlining, open `references/paragraph-flow.md`.

## 8. Return prose plus notes

Output the draft together with explicit notes on assumptions, missing inputs, and where evidence is needed. See `output-format.md`.

## 9. Revise by targeted edit, not full rewrite

When the user reacts to a draft, "this is not what I meant" is usually local — a wrong claim, a mis-framed paragraph, the wrong result leading. Do not silently re-draft the whole section: a full rewrite breaks the paragraphs that were already right and forces the user to re-check everything.

- Change **only** the paragraphs or claims the user flagged; keep the rest verbatim.
- If a requested fix genuinely forces a structural change (reordering sections, moving a claim across paragraphs), say so and confirm the new structure before applying it, rather than restructuring silently.
- Keep the Terminology Ledger (step 1b) stable across revisions unless the user changes a term; never let a revision reintroduce a variant of a locked term.
- After revising, re-run only the checks relevant to what changed (steps 5-7), not the whole workflow.
- If the user's redirection reveals the original premise was wrong, return to the confirmation gate (step 3b) instead of patching prose on a broken premise.
- Every proposed addition triggers the main-text deletion check: identify the
  new sentence's function, find existing text with the same function, and prefer
  replacement or compression before appending. Re-run the paragraph necessity
  and claim-repetition checks after the edit.

# Journal: generic — writing

Used when the user has not named a target journal, or the journal is not specifically modeled by another fragment.

## Defaults

- Apply Nature-leaning structure (argument chain, section jobs) without enforcing Nature's strictest length or significance-framing demands.
- Keep em-dash and hedging defaults from `core/stance.md` and `language/en.md`.
- If the user later names a journal, ask whether to re-draft under that journal's fragment rather than guess.

## Things to ask the user before final draft

- Target journal and section format (structured vs unstructured abstract; word limits; reference style).
- Audience breadth: subfield vs broad readership.
- Whether a "Significance" paragraph or "Author summary" is required.
- Required submission elements (graphical abstract, highlights, key points) — these change drafting strategy.

# Journal: Nature Communications (writing)

## Read the shared facts first

Open `../../../../nature-shared/journal-formats/nat-comms.md` for the authoritative formatting facts: word limits, abstract rules, figure specs, reference style, mandatory statements, and common desk-rejection patterns.

The notes below are the **drafting action layer** on top of those facts.

## Audience

Open-access, broader than a subfield journal, more specialist-tolerant than *Nature*. The reader is typically an active researcher in an adjacent area.

## Drafting priorities

- Significance framing matters, but a less aggressive opening than *Nature* is acceptable.
- Tight prose is still preferred even though limits are looser than *Nature*.
- Methods can be more detailed in-line; reproducibility expectations are explicit.
- Same em-dash and hedging defaults as *Nature*.

## Pre-drafting word budget (Articles)

The ~5,000-word cap **includes Methods**. Before drafting any section, propose a budget and confirm with the user:

| Section | Suggested budget |
|---|---|
| Introduction | ~700 |
| Results | ~2,000 |
| Discussion | ~800 |
| Methods | ~1,500 |
| **Total** | **~5,000** |

Adjust based on paper type:
- Methods-heavy paper → shift toward `~1,200 / 1,800 / 700 / 1,800` (Intro / Results / Disc / Methods)
- Bio/clinical with rich Results → shift toward `~600 / 2,400 / 800 / 1,200`

If the user already has prose, estimate the current split first; if Methods runs >1,800, name it as a budget risk before drafting more.

## Mandatory companion artifacts to plan early

Nature Communications enforces these at production. Mention them at the **planning** stage, not after drafting:

- Data Availability statement with **valid, public accession numbers** (not pre-publication holds)
- Code Availability statement if any custom code is used (Zenodo DOI or equivalent)
- Reporting Summary — fill with the same rigor as the manuscript itself; reviewers see it
- Cover letter (separate upload) — three sentences: what / what's new / why cross-disciplinary

## Display-item planning

- 10-item cap (figures + tables combined)
- **No Extended Data tier** — anything beyond 10 goes to Supplementary Information
- Decide upfront which results justify a main figure vs. Supplementary. Reviewers tolerate fewer main figures more easily than they tolerate overcrowded ones.

## Abstract drafting

- 150 words, unstructured single paragraph, no citations
- Spell out abbreviations at first use
- Lead with the finding, not the background — editors triage on the abstract
- Include quantitative results where possible

## Cross-skill notes

If the user is transferring from a *Nature* draft, the most common rework is:
1. Reabsorb the separate Methods block into the main text word budget
2. Redistribute figures beyond 6 (Nature limit) up to the 10-item cap or into Supplementary
3. Re-tune the opening for a slightly less aggressive significance framing

# Journal: Nature Machine Intelligence — writing

## Read the shared contract first

Open
`../../../../nature-shared/journal-formats/nature-machine-intelligence.md`.
It is the canonical, stage-aware source for NMI content types, word/display
limits, initial files, code/data policy and accepted-in-principle production
rules.

The notes below are the **drafting action layer** on top of those facts.

For Results or Discussion drafting, also open
`../../../../nature-shared/core/nature-results-discussion.md`. It records
corpus-derived Nature-style writing patterns, not official submission
requirements.

For Introduction drafting, also open
`../../../../nature-shared/core/nature-introduction.md`. It records
corpus-derived Nature-style writing patterns, not official submission
requirements.

For abstract drafting, also open
`../../../../nature-shared/core/nature-abstract.md`. It records corpus-derived
Nature-style writing patterns, not official submission requirements.

## Audience and fit

Write for readers across machine learning, robotics, AI applications and the
scientific or societal domain affected by the work. The paper must still be
technically exact, but the title, abstract and opening should explain the
question and consequence without assuming one benchmark community's jargon.

Do not equate a larger model, more compute, a small benchmark gain or an extra
dataset with NMI-level significance. State what scientific, technical or
societal understanding changes and bound transfer claims to the evaluated
settings.

## Article drafting contract

- Budget no more than 3,500 words for Introduction + Results + Discussion;
  Methods, abstract, references and legends are outside this count.
- Keep the unreferenced abstract at no more than 150 words.
- Use at most six figures and tables combined in the main display budget.
- Plan around about 50 references unless the editor permits more.
- Use an unheaded introduction followed by Results, Discussion and Methods.
- Results and Methods may use topical subheadings; Discussion should not.

Suggested starting budget for an Article:

| Section | Suggested budget |
|---|---:|
| Introduction | 550–700 words |
| Results | 2,100–2,350 words |
| Discussion | 500–750 words |
| **Counted main text** | **up to 3,500 words** |

Methods has no fixed public numeric limit. Keep it concise, complete and
reproducible instead of hiding essential details in Supplementary Information.

## Machine-intelligence evidence gates

Before strong novelty, generality or deployment language, ask for:

- genuinely independent test data and leakage controls
- baseline parity in data, supervision, tuning budget and compute
- uncertainty, repeated runs and ablations for the claimed mechanism
- robustness, failure cases and out-of-distribution limits
- compute, hardware, software and environment detail sufficient to reproduce
  the result
- population, setting, human factors and prospective validation for real-world
  or societal claims

New code central to the conclusions requires a separate Code availability
section, reviewer access and the Software Submission Checklist. Plan these
artifacts while drafting Methods rather than after acceptance.

## Results–Discussion action

- Build Results as claim escalation: each subsection should answer a new
  scientific question and add an independent inference.
- Allow a bounded local explanation in Results when it directly resolves the
  experiment just reported; reserve cross-result, literature, and broader
  implications for Discussion.
- Keep robustness in the main text when it establishes or materially bounds a
  claim; route reassurance-only checks to SI.
- Let Discussion briefly anchor the central finding, then synthesize rather
  than replay the Results evidence and statistics.

## Introduction action

- Narrow quickly from the important problem to a specific unresolved
  phenomenon, condition, mechanism, or contradiction.
- State the gap as an exact unknown; do not define it as the absence of the
  author's method.
- Organize literature to construct the known–unknown transition, not to display
  coverage.
- Let the study's answer emerge only after the question is motivated, and use
  the closing paragraph as a compact roadmap of how the study answers it.
- Require every central Introduction question to map to a Results answer and
  every central Results claim to have a motivated question.

## Abstract action

- Treat the abstract as the manuscript's shortest evidence chain, not a
  compressed Introduction or experiment inventory.
- State one sharp gap, the minimum design logic needed to answer it, one main
  discovery, and no more than one or two decisive supports or boundaries.
- Include a number only when it defines, supports, or materially bounds the
  central claim; a decorative numeric result is not required.
- End with what the finding changes or enables within the tested scope, not
  with a claim that the method performs well.

## Submission-package actions

- Treat the cover letter as part of the initial package. State importance,
  NMI readership fit, related manuscripts and prior editor discussions.
- If the manuscript extends a conference paper, identify the substantial new
  results, methodology, analysis, conclusions or implications explicitly.
- For double-anonymized review, move author contact information to the cover
  letter and audit repositories, self-citations, acknowledgements and metadata.
- Do not offer a presubmission enquiry; NMI does not consider them.

## Numeric non-invention rule

The current public NMI pages do not state a fixed title limit, Methods word
limit or current separate per-legend word limit. Do not borrow those numbers
from flagship Nature or Nature Communications. For figure legends, retain the
official 2018 NMI below-300-word instruction only as a historical advisory:
count the complete legend rather than each panel, aim for 150–250 English words,
and follow any newer editor or submission-system instruction.

# Journal: Nature Portfolio title — writing

Use this value when the user names a Nature Portfolio subjournal other than
Nature Communications, or asks for Nature-family style without naming the
flagship journal Nature.

## Audience and writing stance

- Aim for a broad scientific audience while respecting the named journal's
  actual scope.
- Surface significance early without turning a field-specific result into an
  unsupported universal claim.
- Define unavoidable specialist terminology and minimize non-standard
  abbreviations.
- Keep title, abstract and opening paragraphs intelligible outside the immediate
  subfield.
- Calibrate causal and novelty claims to the supplied evidence.

## Requirement gate

Do not import flagship Nature's 75-character title, 2,500/4,300-word budget,
Extended Data tier, figure-legend limit or reference budget automatically.
Check the named journal's current article-type instructions and record the
source and verification date before applying exact numbers.

If the user actually means the flagship journal Nature, switch the journal axis
to `nature` and load `../nature-shared/journal-formats/nature.md` through the
manifest route.

# Journal: flagship Nature — writing

This fragment applies only to an Article submitted to the flagship journal
**Nature**. It does not supply exact rules for Nature Portfolio subjournals.

## Audience

Broad, multi-disciplinary. A reader outside the immediate subfield must be able to grasp the claim, the gap, and the significance from the first paragraph of the introduction and from the abstract alone.

## Drafting priorities

- The opening sentence of the abstract and the introduction must signal significance for a non-specialist audience without overclaiming.
- For a `Nature` summary paragraph, use a staged funnel: `broad field -> sharper background -> exact problem -> here we show -> what the result changes -> broader context / outlook`.
- Avoid jargon that does not appear in a typical Nature News piece. Define or replace.
- At initial submission, formatting is flexible within reason. Use the target
  length and display budget as a readiness check, not as grounds to reject an
  otherwise reviewable file. Apply strict production formatting only at the
  stage requested by the editor.
- No em dashes in body prose.
- Hedging must be calibrated: avoid both overclaim (`proves`, `definitive`) and timidity (`might possibly suggest`).
- The "Significance" framing matters. If the user's material does not naturally support broad significance, surface that before drafting around it.

## Section format notes

- Articles begin with a fully referenced, unstructured summary paragraph aimed
  at readers outside the discipline.
- When the abstract is effectively a `Nature` summary paragraph, make sure the gap sentence and the `Here we show` sentence are both explicit and separated in function.
- Methods follows the figure legends, typically stays within about 3,000 words,
  and must support interpretation and replication.
- References are typically capped at about 50 for the Article main text. Plan
  the citation budget early; Methods and Supplementary references are separate.

## Required companion reference

For formatting, submission-package or readiness work, load
`../../../../nature-shared/journal-formats/nature.md`. It is the canonical,
stage-aware checklist for the current flagship Nature Article requirements.

When the manuscript involves human or animal research, clinical research,
reporting summaries, image integrity, structures, chemistry, taxonomy or
provenance-sensitive samples, also load
`../../../../nature-shared/core/research-compliance.md`.

## Things to flag rather than silently fix

- If the manuscript leans on a specialist mechanism the broad audience cannot follow, flag it rather than over-translating.
- If significance for a non-specialist is genuinely thin, surface that as a structural issue under `Assumptions or missing inputs:`.

# Language: English source (writing)

When the source notes are already in English, default to standard scientific-English drafting conventions.

## Sentence rules

- Aim for `10-30` word sentences in drafts.
- One main proposition per sentence; split if the sentence carries two.
- Prefer subject-verb-object order. Avoid stacked prepositional chains.
- Avoid em dashes as prose punctuation in drafts unless the user explicitly asks. Use commas, parentheses, or short sentences.

## Paragraph rules

- One paragraph, one message.
- The first sentence is the topic or claim.
- Each subsequent sentence has an explicit relation to the previous one: cause, comparison, restriction, example.
- Do not stack two ideas into one paragraph. If a new idea appears, start a new paragraph.

## Diction

- Calibrate verbs to evidence strength (`show` / `suggest` / `may`).
- Avoid marketing verbs (`leverages`, `enables`, `empowers`) unless they carry concrete information.
- Avoid universal claims (`always`, `never`, `comprehensive`).

# Language: Chinese-to-English (writing)

Use this when the user's notes are Chinese, mixed Chinese-English, or organized as lab notes rather than manuscript prose.

## Translate intent, not syntax

Chinese academic notes often pack background, motivation, method, and implication into one long sentence. Before drafting English, split each note into:

- claim
- evidence
- condition
- comparison
- implication
- limitation

Then write English in the order required by the section, not in the order of the Chinese sentence.

## Common repairs

| Chinese-draft pattern | English repair |
|---|---|
| Broad importance before a clear object | Name the system or problem earlier |
| Method list before research gap | Move the gap before the method |
| `显著提高 / 明显改善` without baseline | Add the comparator or soften the verb |
| `首次 / 创新性` without scope | Replace with a bounded novelty claim |
| Mechanism inferred from correlation | Use `suggests`, `is consistent with`, or ask for mechanistic evidence |
| Results mixed with implications | Put observation in Results, meaning in Discussion |
| Repeated topic noun where English would use a pronoun | Replace or elide |
| Strings of short clauses joined by commas | Split or add explicit connectives |

## Output convention

For Chinese-author notes, provide polished English **first**, then brief Chinese notes explaining major structural choices. This lets a Chinese author verify intent without re-reading the English from scratch.

## Deeper reference

For more repair patterns and edge cases, open `references/chinese-author-workflow.md`.

# Paper type: algorithmic or device

A procedure, tool, or system is proposed; the paper must show it performs reliably and advantageously.

## Argument chain

`task definition + scope -> what the system is -> why it works (design rationale) -> how well it works (evaluation) -> ablations isolating the contribution -> failure modes + cost characteristics -> applicability boundary`

## Drafting rules

- Separate "what the system is" from "why it works" from "how well it works." Do not braid them. A common failure is mixing design rationale with evaluation results in the same paragraph.
- Every performance claim must specify dataset, metric, baseline, and conditions. Bare numbers do not survive review.
- Avoid marketing verbs (`leverages`, `enables`, `empowers`) unless they carry concrete information.
- The Discussion must name the failure modes the experiments revealed, not only the wins. Reviewers trust papers that report their own limits.

## Module / pipeline writing

For module-level writing (each component of a pipeline), open `references/method.md` for:

- the three-element pattern (motivation, mechanism, evidence)
- module-motivation templates
- overview-template for the pipeline figure caption + first paragraph

# Paper type: hypothesis-based

The argument tries to establish or rule out a causal explanation.

## Argument chain

`phenomenon -> candidate explanation(s) -> hypothesis stated explicitly -> falsification path -> evidence for / against -> rival explanations addressed -> bounded conclusion`

## Drafting rules

- State the hypothesis explicitly and locatably. Do not bury it in the third paragraph of the Introduction.
- State up front what observations would refute the hypothesis. This earns trust later.
- Distinguish "supporting" evidence from "consistent but non-discriminating" evidence. Many drafts conflate them.
- In Discussion, address rival explanations **before** generalizing. Skipping this is the most common rejection point for hypothesis papers.
- Hedging must match causal strength. Correlational evidence cannot ground mechanism verbs (`drives`, `causes`).

## Results vs Discussion

Keep Results to direct observations and tests. All causal interpretation goes in Discussion. Reviewers will check this split aggressively.

# Paper type: methods

A methods paper proposes a technique and must convince the reader it works, is reproducible, and is better than alternatives under a fair test.

## Argument chain

`task / problem -> limits of existing methods -> proposed method -> evaluation showing advantage -> reproducibility evidence -> boundary`

## Drafting order

1. Methods — the technical core, written first
2. Results — what comparisons and ablations show
3. Introduction — frames the task and gap retrospectively
4. Conclusion
5. Discussion
6. Abstract

## Results section discipline

In a methods paper, Results must answer:

- Is it more reliable?
- Is it faster / cheaper / smaller?
- Does it require fewer resources or data?
- Is the comparison fair and reproducible?

Bare "we obtain higher accuracy" without baseline + setup + statistical handling is insufficient.

## Methods section depth

Be explicit about:

- axioms, conditions, and assumptions
- hardware and software environment
- mathematical derivations
- evaluation protocol: datasets, baselines, metrics, splits, hyperparameters
- failure modes and out-of-scope conditions

When drafting a method, also open `references/method.md` for module-motivation and three-elements patterns.

# Paper type: research

A research paper answers: why this phenomenon matters, what was done, what was found, what it implies.

## Full-paper argument chain

`field-scale need -> unresolved bottleneck -> proposed move -> decisive evidence -> broader implication -> boundary`

Before drafting, force the user's material into this chain. If one link is missing, mark it as missing rather than writing around it.

## Drafting order

For a research paper, draft in evidence-first order:

1. Results — write what was observed before anything else
2. Introduction and Conclusion — frame around the actual results
3. Title — derived from the strongest result + scope
4. Discussion — interpret in dialogue with prior work
5. Methods — written for reproducibility, not narrative
6. Authors — order and contributions
7. Abstract — last, distilled from the rest

Do not draft Introduction before Results. The Introduction's job is to set up the gap that Results actually fills.

## Hourglass structure

Strong research papers mirror an hourglass:

- Introduction: broad → narrow to specific gap, question, hypothesis, methods
- Discussion/Conclusion: narrow → broad, connecting findings back to the field

If a draft violates this, rebuild architecture before drafting paragraphs.

# Paper type: review

A review reports on the state of a field: what is known, where the disagreements are, what remains open.

## Argument chain

`scope statement -> organizing principle (mechanism / method / application) -> synthesis grouped by argument -> disagreements and gaps -> author's stance with reasoning -> outlook with informative open questions`

## Drafting rules

- A review is **not a survey list**. Replace `Author A reported X. Author B reported Y.` with synthesis grouped by mechanism, method, or conclusion.
- Define scope precisely: which sub-area, which time window, which inclusion criteria. Vague scopes invite reviewer pushback.
- Position the reviewer's own stance carefully. A review can take a view, but it must show its reasoning, not assert it.
- Use connectives that signal logical relation: `in contrast`, `building on this`, `the remaining disagreement is`. Avoid generic `furthermore`, `additionally`.
- The closing section should leave the reader with a usable map of the field, not a summary of what was just read.

## Related work synthesis

For topic-based grouping techniques and how to write distinctions without bashing prior work, open `references/related-work.md`.

# Section: Abstract (writing)

The abstract is the manuscript's shortest evidence chain, not a compressed
Introduction. Draft it last, when Results and Discussion are stable.

## Default Nature pattern

`precise problem / gap -> answer-enabling design -> main discovery -> decisive support / boundary -> implication`

## Paragraph movement (recommended)

1. State the problem and exact unresolved question with minimal background.
2. Explain only the design logic needed to see how the question is answered.
3. State one main discovery.
4. Add one or two decisive supporting findings or boundaries.
5. End with the bounded conceptual, technical, or field-level implication.

## Pattern variants for technical / method-heavy papers

For ML, CV, materials, or method-heavy manuscripts, choose one variant from `references/abstract.md`:

- `challenge -> contribution`
- `challenge -> insight -> contribution`
- `multiple contributions`

Open `references/abstract.md` for templates and examples.

## Diagnostics before submitting the draft

- Beginning with `Here, we` may signal missing context.
- Ending with a broad promise may need scope control.
- A result may feel ungrounded when neither a decisive comparison nor the logic
  of the supporting test is visible. A number is optional unless it defines the
  central claim.

## Drafting discipline

- Keep it compact. Cut sentences that re-summarize background the title already implies.
- Include a quantitative result only when it defines, supports, or materially
  bounds the central claim. Do not invent numbers or fill the abstract with an
  experiment inventory.
- Keep one main claim and no more than one or two supporting claims.
- End with what the work enables, not generic importance.

# Section: Conclusion (writing)

## Default structure

`contribution -> decisive evidence -> implication -> boundary`

## Drafting rules

- No new data. No unsupported promises.
- Restate the central contribution in one sentence. Do not summarize each Result figure.
- The implication must be narrower than or equal to the scope of the evidence.
- A bounded future-work pointer is acceptable, but generic "more work is needed" is not.

## Overclaim check

Before finalizing, run the check:

- Does each claim trace back to evidence in this paper?
- Are mechanism words (`demonstrates`, `proves`, `establishes`) backed by the right study design?
- Is the scope of the implication narrower than or equal to the scope of the evidence?
- Is any "first" claim genuinely first within a stated scope?

## Deeper reference

For full conclusion structure (contribution-evidence-impact-limitation-future), open `references/conclusion.md`.

# Section: Discussion (writing)

Load `../../../../nature-shared/core/discussion-argument-language.md` for the
complete Discussion function chain, modality ladder, limitation logic, and
sentence-function audit.

## Default structure

`central advance -> what the evidence means -> relation to prior work -> constraints / limitations -> future use or open questions`

## Drafting rules

- Discussion **synthesizes across established Results claims**; it does not
  repeat the evidence figure by figure.
- Address rival explanations before generalizing. Reviewers look for this.
- Hedging strength must match evidence strength. Do not promote a "consistent with" finding to "demonstrates" wording.
- Limitations come from inside the paper, not from generic disclaimers. Name the specific condition or dataset where the result stops holding.

## Sentence syntax

Discussion sentences interpret:

- `may reflect`
- `suggests that`
- `could indicate`
- `is likely due to`
- `may facilitate`

## Common failure modes when drafting

- Re-summarizing Results instead of interpreting them.
- Skipping rival explanations.
- Omitting boundaries — when does the interpretation stop holding?
- Future-work statements that read as marketing, not as honest open questions.
- Treating the reverse funnel as a fixed paragraph template or expanding beyond
  what the evidence supports.
- Using `must`, `cannot`, `demonstrates`, or causal verbs without naming the
  design feature that licenses that strength.
- Listing limitations without saying which claim, scope, or interpretation each
  one changes.

## Short rule to memorize

- Results = the evidence chain that establishes and advances claims
- Discussion = what those claims mean together, how they relate to the field,
  and when the synthesis may fail

# Section: Experiments / Results (writing)

## Default evidence ladder

`establish the phenomenon -> stress-test it -> rule out alternatives -> broaden it -> interpret it -> bound it`

Each subsection has a claim-first opening, then data support.

Depending on the paper, instantiate this as a discovery loop, a core-capability
plus validation envelope, or a capability ladder. Load
`../../../../nature-shared/core/nature-results-discussion.md` for the three
archetypes and the same-level-repetition test.

## Drafting rules

- Load `../../../../nature-shared/core/main-text-discipline.md` before deciding
  which analyses enter the main text. Classify results by their function in the
  paper and build the shortest sufficient evidence chain.
- Stay mainly in past tense.
- Report what was observed, under what conditions, with what quantitative support.
- Use statistics correctly and sparingly. Every test needs a stated hypothesis.
- Keep core discovery and necessary support in the main text. Route robustness,
  non-central heterogeneity, provenance detail, alternative inference, and edge
  cases to SI unless they change the central interpretation.
- **Each major claim needs adequate evidence across the manuscript and SI.** Do
  not force every comparison, ablation, or stress test into the main text; if
  adequate evidence is absent from the full record, mark it for follow-up rather
  than drafting around it.
- Normally report the descriptive quantity and primary inferential statistic in
  the main text. Put secondary inference and diagnostics in SI unless required
  or conclusion-changing.

## Results syntax (vs Discussion)

Results sentences usually report:

- `was detected` / `increased` / `showed` / `enabled` / `achieved`

Close each coherent evidence unit with the bounded inference it supports.
Calibrated interpretation (`suggests`, `indicates`, `likely because`) may remain
in Results when it directly answers the current experiment and the supporting
evidence is visible there. Move literature synthesis, broad implications, and
extended mechanistic reconciliation to Discussion.

## Common failure modes when drafting

- Mixing observation with an interpretation that is not supported by the
  current experiment, or allowing local interpretation to expand into a broad
  Discussion.
- Citing supplementary data when the result should be in the main text.
- Appending robustness or reviewer-defense prose until the central evidence chain
  disappears.
- Repeating the same effects, intervals, and P values in Results and captions.
- Vague comparisons (`higher than control`) without effect size, sample size, or test.
- Per-paragraph claims without per-paragraph evidence.
- Reusing an earlier baseline or control as the centre of a later subsection
  and restating the same claim, instead of making the new perturbation,
  falsification, stronger comparator, or boundary the decisive evidence.

## Deeper reference

For ML/conference-style experiment sections — baselines, ablations, metrics, tables, figures — open `references/experiments.md`.

# Section: Introduction (writing)

## Default funnel

`important problem -> specific phenomenon or difficulty -> what prior work establishes -> exact unresolved gap -> research question or hypothesis -> present study`

For a broad-audience `Nature` summary paragraph, strengthen this into (See `references/nature-summary-paragraph.md`.):

`broad field -> sharper background -> exact problem -> here we show -> what the result changes -> broader context / outlook`

## Paragraph jobs (typical 4-paragraph intro)

1. Establish the field stake. Make it land for a non-specialist if the target is broad (Nature, Science).
2. Narrow quickly to the specific phenomenon, tension, or bottleneck.
3. Summarize what prior work has and has not resolved. Synthesize, do not list.
4. State the exact unknown and research question, then explain how this paper
   addresses it. Preview the study route, not the Results in detail.

## Pipeline variants — pick one based on the material

For method-heavy papers, the introduction often follows a different pattern. Common variants from curated examples (open `references/introduction.md` and `references/examples/introduction-examples.md` for full versions):

- **task-then-application** — define a task abstractly, then show its applications
- **application-first** — open with a concrete application or pain point, narrow to the task
- **general-to-specific-setting** — broad field → specific subproblem
- **open-with-challenge** — lead with the unsolved difficulty
- **novel-task-challenge-decomposition** — define a new task, decompose its challenges
- **technical-challenge** (1-3 variants) — frame around the technical bottleneck, then the move
- **pipeline-version** (1-4 variants) — for module/pipeline papers, frame contribution as one or several modules

Tell the user which variant you picked and why.

## Drafting rules

- Do not summarize results in detail. The final paragraph states the contribution and approach, not the numbers.
- Cite prior work to position, not to demonstrate breadth. Each citation should earn its place.
- The transition from "what is known" to "what this paper does" must be explicit, not implied.
- Define the gap as an unknown, disputed condition, mechanism, or boundary; do
  not define it as the absence of the author's method.
- Make each background paragraph narrow toward the research question. Delete or
  compress field history that does not prepare a question answered in Results.
- Draft backward from the Results claims: every central Introduction question
  needs a Results answer, and every central Results claim needs a motivated
  question.

# Section: Method (writing)

## Default structure

`task formulation -> overview (pipeline / system / approach) -> per-module detail -> implementation notes -> assumptions and boundary`

## The three-element pattern (per module)

Each module should answer:

1. **Motivation** — what problem this module solves, and why the obvious alternative fails
2. **Mechanism** — what the module actually does, to a level a peer could re-implement
3. **Evidence / role** — how this module contributes to the overall result (ablation hook)

If any element is missing, the module reads as a black box. Flag the gap.

## Pre-writing checklist

Before drafting Method, confirm with the user:

- Task formulation: inputs, outputs, scope.
- Overview figure / pipeline diagram: does one exist? It anchors the section.
- Notation: defined once and consistent.
- Reproducibility scope: code, weights, data — what will be released.

## Forbidden vague phrases

Never leave:

- `under standard conditions`
- `using routine methods`
- `data were analyzed statistically`
- `the method was validated`
- `samples were randomly assigned` (without saying how)

Replace with the actual reproducible information.

## Deeper reference

For module-motivation templates, three-elements examples, and overview-template patterns, open `references/method.md` and `references/examples/method/`.

# Section: Related Work (writing)

## Default structure

`topic scope -> representative methods grouped by mechanism -> limitation tied to this paper -> distinction`

## Drafting rules

- **Group by technical topic and mechanism, not by publication year or author.** A paragraph titled "Graph-based approaches" with three contrasting methods is stronger than three single-paper paragraphs.
- Each subsection ends with a limitation that **this paper addresses**. If a subsection's limitation does not connect back to your contribution, the subsection probably does not belong.
- Avoid both extremes: do not bash prior work, do not flatter it. State what prior work showed and where its scope ended.
- Cite the source you actually read. Do not chain-cite review papers as if they were primary sources.

## When Related Work is a separate section vs folded into Introduction

- Separate Related Work is common in CS/ML conference style.
- Folded into Introduction is common in Nature-family style.
- The user's target venue decides. Ask if unclear.

## When to open the deep reference

For topic-based synthesis techniques and concrete patterns, open `references/related-work.md`.

# Section: Title (writing)

## Default pattern

Prefer concrete titles that combine:

`system / object + action / capability + application or consequence`

## Drafting rules

- Tell the reader what to expect; do not be a slogan.
- Be searchable: include terms a researcher would search for.
- Be substantiated by data — if a number or quantitative word appears, verify it against the manuscript.
- Create curiosity without sacrificing credibility. A hook is only acceptable if the claim remains fully defensible.

## Things to avoid

- Grant-style aims (`Toward …`, `A study of …`).
- Overbroad field claims (`A new era of …`, `Revolutionizing …`).
- Question titles unless the paper genuinely answers the question.
- Jargon a non-specialist in the target audience would not recognize.

## When asked for alternatives

Generate 3-5 candidates spanning declarative, finding-led, and (rarely) question patterns. Mark the most defensible one. Verify any quantitative claim in each candidate.

# Manuscript task

Use the normal section-writing workflow. Build the paper argument, load the requested section fragment, draft from evidence outward, and return the prose with claim-evidence notes.

Do not add submission forms or editorial correspondence unless the user asks for them.

# Initial submission package

Use this task only before the first editorial decision. Read `references/submission-package.md` for the full intake contract, templates, and readiness checklist.

## Core workflow

1. Identify the target journal, article type, manuscript title, corresponding author, and requested deliverables.
2. Check the journal's current author instructions when exact requirements matter. Treat journal-specific instructions as authoritative.
3. Record the submission stage. Do not apply accepted-in-principle production
   rules as initial-submission blockers.
4. For the flagship journal Nature, load
   `../../../../nature-shared/journal-formats/nature.md`; load the conditional
   research-compliance reference when its applicability gate is triggered.
   For Nature Machine Intelligence, load
   `../../../../nature-shared/journal-formats/nature-machine-intelligence.md`
   and treat the cover letter, availability statements and central-code review
   access as initial-package checks.
5. Build a deliverable matrix: required, optional, not applicable, or author input needed.
6. Draft only from author-supplied facts. Never invent author identities, affiliations, ORCIDs, funding numbers, ethics approvals, repository links, accession numbers, conflicts, reviewer identities, or permissions.
7. Keep the initial cover letter concise and editor-facing: what the study shows, what is new, why it fits the journal/readership, and any required declarations.
8. Keep each declaration internally consistent with the manuscript and title page.
9. Return a readiness state: `ready`, `ready_with_author_checks`, or `blocked`.

## Default deliverables

- Initial-submission cover letter when required or useful. For the flagship
  journal Nature it is optional and must not be treated as a blocker.
- Title-page metadata checklist or draft.
- Three to five highlights when the journal accepts them.
- CRediT-style author-contribution statement.
- Data and code availability statements.
- Competing-interests, funding, acknowledgements, and ethics statements.
- Suggested/opposed reviewer table when requested.
- Related-manuscript, preprint, originality, permissions, and reporting-checklist prompts.
- Submission completeness matrix.
- Stage-specific file preflight: initial submission versus revision versus
  accepted-in-principle production files.
- Filled LaTeX deliverables from `templates/submission/` when the user requests `.tex` files.

Graphical abstracts and TOC graphics belong to `nature-figure`. Revision cover letters and rebuttals belong to `nature-response`.

\documentclass[10pt]{article}

\usepackage[margin=0.8in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{longtable}
\usepackage{array}
\usepackage{hyperref}

\title{Submission Declarations and Reviewer Suggestions\\
\large AUTHOR\_INPUT\_NEEDED: Manuscript title}
\author{}
\date{}

\begin{document}
\maketitle

\section*{Submission declarations}

\subsection*{Originality and author approval}
AUTHOR\_INPUT\_NEEDED: Confirm originality, absence of prohibited concurrent
submission, and approval by all authors using the journal's required wording.

\subsection*{Author contributions}
AUTHOR\_INPUT\_NEEDED: CRediT roles confirmed by all authors.

\subsection*{Competing interests}
AUTHOR\_INPUT\_NEEDED: Declaration.

\subsection*{Funding}
AUTHOR\_INPUT\_NEEDED: Funder names and grant identifiers, or no specific funding.

\subsection*{Data availability}
AUTHOR\_INPUT\_NEEDED: Real repository, accession number, embargo, and access conditions.

\subsection*{Code availability}
AUTHOR\_INPUT\_NEEDED: Real repository, version, license, and access conditions, or not applicable.

\subsection*{Ethics and consent}
AUTHOR\_INPUT\_NEEDED: Ethics approval, consent, and publication-consent statements, or not applicable.

\subsection*{Preprint and related manuscripts}
AUTHOR\_INPUT\_NEEDED: DOI or URL and relationship to this submission, or none.

\subsection*{Third-party permissions}
AUTHOR\_INPUT\_NEEDED: Permission status for reused figures, tables, instruments, or other material.

\section*{Suggested reviewers}

\begin{longtable}{>{\raggedright\arraybackslash}p{0.11\textwidth}
                  >{\raggedright\arraybackslash}p{0.15\textwidth}
                  >{\raggedright\arraybackslash}p{0.17\textwidth}
                  >{\raggedright\arraybackslash}p{0.14\textwidth}
                  >{\raggedright\arraybackslash}p{0.12\textwidth}
                  >{\raggedright\arraybackslash}p{0.12\textwidth}}
\textbf{Name} & \textbf{Institution} & \textbf{Email} &
\textbf{Expertise fit} & \textbf{Conflict check} & \textbf{Rationale}\\
\hline
Input needed & Input needed & Input needed &
Input needed & Author confirmation needed & Input needed\\
\end{longtable}

\section*{Opposed reviewers, if permitted}

\begin{longtable}{>{\raggedright\arraybackslash}p{0.2\textwidth}
                  >{\raggedright\arraybackslash}p{0.25\textwidth}
                  >{\raggedright\arraybackslash}p{0.45\textwidth}}
\textbf{Name} & \textbf{Institution} & \textbf{Factual reason}\\
\hline
Input needed & Input needed &
AUTHOR\_INPUT\_NEEDED: concise, non-personal reason\\
\end{longtable}

\end{document}

\documentclass[11pt]{article}

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{enumitem}

% Check the target journal's bullet count and character limits before submission.

\title{Highlights and Editorial Summary\\
\large AUTHOR\_INPUT\_NEEDED: Manuscript title}
\author{}
\date{}

\begin{document}
\maketitle

\section*{Highlights}

\begin{itemize}[leftmargin=*]
  \item AUTHOR\_INPUT\_NEEDED: Concrete principal finding.
  \item AUTHOR\_INPUT\_NEEDED: Specific methodological or conceptual advance.
  \item AUTHOR\_INPUT\_NEEDED: Strongest evidence or comparison.
  \item AUTHOR\_INPUT\_NEEDED: Bounded implication for the field or practice.
  \item AUTHOR\_INPUT\_NEEDED: Optional fifth highlight or remove this item.
\end{itemize}

\section*{Editorial summary or significance statement}

AUTHOR\_INPUT\_NEEDED: State the problem and intended audience.

AUTHOR\_INPUT\_NEEDED: State the principal advance and evidence.

AUTHOR\_INPUT\_NEEDED: Explain why the result changes understanding or practice,
while preserving the manuscript's scope and limitations.

\end{document}

\documentclass[11pt]{letter}

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{hyperref}
\usepackage{setspace}

% Replace every AUTHOR_INPUT_NEEDED placeholder with author-confirmed facts.
% This template is for an initial submission, not a revision or rebuttal.

\signature{AUTHOR\_INPUT\_NEEDED: corresponding author name\\
on behalf of all authors}
\address{AUTHOR\_INPUT\_NEEDED: affiliation\\
AUTHOR\_INPUT\_NEEDED: email and postal address}
\date{\today}

\begin{document}

\begin{letter}{AUTHOR\_INPUT\_NEEDED: editor name or Editors\\
AUTHOR\_INPUT\_NEEDED: journal name}

\opening{Dear AUTHOR\_INPUT\_NEEDED: Editor name or Editors,}

Please consider our manuscript entitled
\emph{AUTHOR\_INPUT\_NEEDED: manuscript title}
for publication as a
AUTHOR\_INPUT\_NEEDED: article type
in \emph{AUTHOR\_INPUT\_NEEDED: journal name}.

AUTHOR\_INPUT\_NEEDED: In one or two sentences, state the problem addressed and
the principal finding, using only results supported by the manuscript.

AUTHOR\_INPUT\_NEEDED: In one or two sentences, explain the specific advance and
the strongest evidence supporting it. Avoid unsupported priority claims.

AUTHOR\_INPUT\_NEEDED: In one sentence, explain why the finding matters to the
journal's readership and scope.

AUTHOR\_INPUT\_NEEDED: Add only journal-required declarations, such as
originality, approval by all authors, preprint or related-manuscript disclosure,
and competing interests.

Thank you for your consideration.

\closing{Sincerely,}

\end{letter}
\end{document}

\documentclass[11pt]{article}

\usepackage[margin=1in]{geometry}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage{authblk}
\usepackage{hyperref}
\usepackage{enumitem}

% Confirm journal placement rules before keeping declarations on this page.
% For double-anonymous review, upload this separately from the anonymous manuscript.

\title{AUTHOR\_INPUT\_NEEDED: Full manuscript title}

\author[1]{AUTHOR\_INPUT\_NEEDED: Author One}
\author[2]{AUTHOR\_INPUT\_NEEDED: Author Two}
\affil[1]{AUTHOR\_INPUT\_NEEDED: Affiliation one}
\affil[2]{AUTHOR\_INPUT\_NEEDED: Affiliation two}

\date{}

\begin{document}
\maketitle

\noindent\textbf{Running title:}
AUTHOR\_INPUT\_NEEDED: Short title

\medskip
\noindent\textbf{Corresponding author:}
AUTHOR\_INPUT\_NEEDED: Name, affiliation, postal address, email, and ORCID

\medskip
\noindent\textbf{Equal or senior contribution notes:}
AUTHOR\_INPUT\_NEEDED: Statement or not applicable

\medskip
\noindent\textbf{Keywords:}
AUTHOR\_INPUT\_NEEDED: Keywords

\medskip
\noindent\textbf{Article type:}
AUTHOR\_INPUT\_NEEDED: Article type

\medskip
\noindent\textbf{Counts:}
AUTHOR\_INPUT\_NEEDED: Word count; number of figures, tables, and supplementary files

\section*{Author contributions}
AUTHOR\_INPUT\_NEEDED: CRediT roles confirmed by all authors.

\section*{Competing interests}
AUTHOR\_INPUT\_NEEDED: Declaration.

\section*{Funding}
AUTHOR\_INPUT\_NEEDED: Funder names and grant numbers, or no specific funding.

\section*{Acknowledgements}
AUTHOR\_INPUT\_NEEDED: Acknowledgements, or none.

\section*{Data availability}
AUTHOR\_INPUT\_NEEDED: Real repository, accession, access conditions, or justified statement.

\section*{Code availability}
AUTHOR\_INPUT\_NEEDED: Real repository, version, license, access conditions, or not applicable.

\section*{Ethics and consent}
AUTHOR\_INPUT\_NEEDED: Approval body and identifier, consent statement, or not applicable.

\end{document}