yuan1z0825/nature-skills已通過檢查

SKILL DETAIL

researchwrite

yuan1z0825/nature-skills/researchwrite

researchwrite is a proposal-first scientific writing pipeline, installed under the compatibility trigger researchwrite and the repository package name nature-proposal-writer. It is used for composing, revising, or auditing research proposals, opening reports, research plans, and evidence-grounded scientific writing. The skill offers three modes (compose/revise/hybrid) with a four-layer QA pipeline. It enforces evidence-before-prose, argument-before-sections, and contracts-before-paragraphs. Inspired by autonovel, professor, brainstorming, and anti-AI-writing, this skill uses a state-machine approach. Core principles include: evidence before prose, argument before sections, contracts before paragraphs, scope before completeness, dynamic experts, content before language, no automatic fact escalation, deletion over explanation, and knowing when to stop. It supports various reference files for different tasks, such as compose mode, revise mode, evaluation rubric, anti-slop, stopping rules, professor dispatch, and more.

安裝量 · 145查看來源

Installation

npx skills add https://github.com/yuan1z0825/nature-skills --skill researchwrite

技能檔案

SKILL.md

最近同步 · 2026年8月27日

agents/openai.yaml›

interface:
  display_name: "Nature Proposal Writer (ResearchWrite)"
  short_description: "Draft evidence-grounded scientific research proposals"
  default_prompt: "Use $researchwrite to draft an evidence-grounded research proposal from these materials."

manifest.yaml›

name: researchwrite
version: 1.1.1
description: >
  Declarative manifest for the proposal-first scientific writing pipeline. The
  skill uses a compact state-machine description and loads its complete set of
  workflow, review, export, and validation references only when they are needed.

# Design note: the installed skill name is researchwrite although the directory
# is nature-proposal-writer. Keep this manifest aligned with the SKILL.md
# frontmatter so `npx skills add --list` exposes the same user-facing name.

always_load:
  - SKILL.md

templates:
  on_demand:
    - condition: initializing a new proposal project or rebuilding the foundation file set
      path: templates/00_scope.md
    - condition: creating or auditing the research canon of hard facts and constraints
      path: templates/01_research_canon.md
    - condition: mapping claims to evidence before prose drafting
      path: templates/02_evidence_table.md
    - condition: building the argument map before section drafting
      path: templates/03_argument_map.md
    - condition: defining section purposes, inputs, allowed claims, and forbidden claims
      path: templates/04_section_contracts.md
    - condition: setting terminology, voice, banned phrases, or anti-slop style rules
      path: templates/05_style_guide.md
    - condition: producing a QA report after the four-gate review pipeline
      path: templates/qa_report.md
    - condition: writing a targeted revision brief after a failed gate or expert review
      path: templates/revision_brief.md

references:
  on_demand:
    - condition: composing a proposal from a topic, direction, or rough idea
      path: references/compose-mode.md
    - condition: revising an existing paragraph, section, chapter, or complete proposal
      path: references/revise-mode.md
    - condition: preserving an existing draft while composing missing or expanded modules
      path: references/hybrid-mode.md
    - condition: scoring a draft or proposal with the 8-dimension rubric
      path: references/evaluation-rubric.md
    - condition: removing generic, inflated, or template-like language from a Chinese proposal
      path: references/research-anti-slop.md
    - condition: drafting or revising a Chinese review article with scientific section titles and evidence-led synthesis
      path: references/chinese-review-writing-style.md
    - condition: deciding whether to continue, stop, split scope, or request more evidence
      path: references/stopping-rules.md
    - condition: dispatching one or more dynamic specialists for scientific content review
      path: references/professor-dispatch.md
    - condition: creating or repairing the five foundation files before drafting
      path: references/foundation-files.md
    - condition: initializing the project directory or reading and updating state.json
      path: references/project-structure.md
    - condition: exporting and archiving Markdown and DOCX deliverables
      path: references/export-archive.md
    - condition: drafting only an approved stage or subsection while preventing scope creep
      path: references/partial-proposal-scope.md
    - condition: inserting or deleting citations that require reference-number cascade updates
      path: references/ref-renumbering-cascade.md
    - condition: designing the question chain, evidence structure, and section architecture of a review paper
      path: references/review-paper-framework.md
    - condition: building critical comparison and evidence-weighted synthesis into a review paper
      path: references/review-critique-methodology.md
    - condition: validating claims, citations, numbering, method reproducibility, or project completeness
      path: references/validation-checklist.md
    - condition: handing a targeted revision task to another agent with constraints and acceptance criteria
      path: references/gpt-handoff-revision-brief.md
    - condition: extending text within an already approved proposal without changing its scientific commitments
      path: references/within-approved-proposal.md
    - condition: consulting a completed materials-science example for the expected depth of foundation files
      path: references/worked-example-quaternary-proposal.md
    - condition: evidence is insufficient for a high-commitment proposal and claims must be deliberately narrowed
      path: references/降承诺提案模式.md

scripts:
  on_demand:
    - condition: exporting a proposal package to DOCX from the generated Markdown files
      path: scripts/build_proposal_docx.py

README_EN.md›

# `nature-proposal-writer` Skill

[中文说明](README.md)

`nature-proposal-writer` is a proposal-first research-writing workflow for turning topics, ideas, drafts, or sections into academic text with argument structure, evidence boundaries, and quality gates.

## What To Use It For

- Build a research canon, problem chain, and section contracts from a rough research direction.
- Revise existing paragraphs so argument order, contribution boundaries, and evidence support are clearer.
- Expand existing drafts into proposals, manuscript sections, review frameworks, or project narratives.
- Run content, language, citation, and formatting QA after drafting.

## Three Modes

| Mode | Input | Best For |
|------|-------|----------|
| `compose` | Topic, direction, rough idea | Build argument and sections from scratch |
| `revise` | Existing paragraph or section | Gap analysis, reordering, and polishing |
| `hybrid` | Draft plus expansion target | Preserve existing text while filling structure |

## Typical Requests

- "I have a grant title; first break down the scientific questions and research content, do not write prose yet."
- "This introduction is scattered; rebuild it with the proposal-first workflow."
- "Expand this draft into a proposal framework and mark evidence gaps."

## What You Need To Provide

- Research topic, target reader, submission/application type, and available materials.
- Confirmed facts, data, figures, references, or wording that must not change.
- Desired length, language, and file format.

## Outputs

- Argument architecture, section contracts, and writing order.
- Ready-to-paste draft text or revised text.
- QA results: content gaps, language risks, citation/numbering issues, and facts that need author confirmation.

## Boundaries

- The skill does not invent experimental results, references, collaboration basis, or feasibility evidence.
- Missing facts are marked as `AUTHOR_INPUT_NEEDED` rather than hidden under fluent prose.
- For sentence-level English polishing only, use `nature-polishing`.

## Complete Reference Set

The skill includes 20 references that are loaded on demand, covering:

- the complete `compose`, `revise`, and `hybrid` workflows;
- foundation files, project state, scope control, and writing within an approved proposal;
- dynamic expert dispatch, scoring, stopping rules, and automated validation;
- Chinese research-writing cleanup, review architecture, and critical synthesis;
- citation renumbering, revision handoffs, export and archival workflows, and a completed example.

See the [reference index and loading conditions](SKILL.md#reference-文件索引) in `SKILL.md`. Load only the references required by the current task rather than injecting the entire set into context.

## Related Skills

- `nature-writing`: Nature-style manuscript-section drafting.
- `nature-polishing`: English manuscript polishing, restructuring, and translation.
- `nsfc-proposal`: dedicated National Natural Science Foundation of China proposal writing.

README.md›

# `nature-proposal-writer` 技能

[English](README_EN.md)

`nature-proposal-writer` 是 proposal-first 的科研写作工作流，用于把题目、想法、草稿或章节扩展为有论证结构、证据边界和质量闸门的科研文本。

## 适合用它做什么

- 从模糊研究方向搭建 research canon、问题链和章节契约。
- 修改已有段落，使论证顺序、贡献边界和证据支撑更清楚。
- 将已有草稿扩写为 proposal、论文章节、综述框架或项目说明。
- 在写作后执行内容、语言、引用和格式层面的 QA。

## 三种模式

| 模式 | 输入 | 适合场景 |
|------|------|----------|
| `compose` | 题目、方向、粗略想法 | 从零建立论证和章节 |
| `revise` | 已有段落或章节 | 做差距分析、重排和润色 |
| `hybrid` | 草稿加扩写目标 | 保留已有文本，同时补足结构 |

## 典型请求

- “我有一个基金题目，帮我先拆科学问题和研究内容，不要直接写正文。”
- “这段 introduction 太散，按 proposal-first 的方式重构。”
- “把这份草稿扩成 proposal 框架，并标出证据缺口。”

## 你需要提供

- 研究主题、目标读者、拟投稿/申报类型和已有材料。
- 已确认的事实、数据、图表、参考文献或不能改动的表述。
- 希望输出的长度、语言和文件格式。

## 产出

- 论证架构、章节契约和写作顺序。
- 可粘贴的正文草稿或修订版。
- QA 结果：内容缺口、语言风险、引用/编号问题和需要作者确认的事实。

## 边界

- 不会替作者虚构实验结果、参考文献、合作基础或可行性证据。
- 对缺失事实会标记 `AUTHOR_INPUT_NEEDED`，而不是用流畅文字掩盖。
- 如果只是句子级英文润色，优先使用 `nature-polishing`。

## 完整参考资料

技能随附 20 个按需加载的 reference 文件，覆盖：

- `compose`、`revise`、`hybrid` 三种模式的完整流程；
- foundation 文件、项目状态、章节范围和已批准框架内写作；
- 动态专家分派、评分、停止规则和自动校验；
- 中文科研写作清理、综述结构与批判性方法；
- 引用编号级联、修订交接、导出归档和完整填写示例。

完整文件索引和加载条件见 [`SKILL.md`](SKILL.md#reference-文件索引)。reference 应按当前任务选择性加载，避免把整套资料一次性注入上下文。

## 相关技能

- `nature-writing`：Nature 风格手稿章节起草。
- `nature-polishing`：英文稿件润色、重构和翻译。
- `nsfc-proposal`：国家自然科学基金申请书的专项写作。

references/chinese-review-writing-style.md›

# Chinese Academic Review Writing Style

本文件规定中文综述写作的通用风格约束。不同于 proposal 写作，综述要求更高的事实密度、更清楚的证据等级和更克制的学术语感。

## 标题命名

标题是结构路标，不是叙事修辞。标题应说明“研究对象 + 分析角度”，避免比喻、拟人、口号和口语化提问。

| 避免 | 原因 | 建议改写 |
|---|---|---|
| “材料命运的决定因素” | 拟人化 | “材料稳定性的影响因素” |
| “参数 X：性能的总开关” | 夸张比喻 | “参数 X 对性能的控制作用” |
| “如何看见界面变化” | 口语化提问 | “界面变化的表征方法” |
| “工程收益与化学代价” | 叙事化 | “处理条件的双重影响” |

## 段落结构

- 每段只承载一个可辨认的论点。
- 论点句在前，证据、比较和限制条件在后。
- 3-5 句的短段落通常优于包含多个论点的长段落。
- 过渡依靠逻辑关系，不依赖“此外”“另一方面”“值得注意的是”等填充词。
- 中文正文如需首行缩进，应在导出规范中统一设置；标题、图注和参考文献除外。

## 禁用或慎用表达

| 表达 | 风险 | 处理方式 |
|---|---|---|
| 随着……的发展 | 万能开头、信息量低 | 直接陈述背景事实 |
| 值得注意的是 | 代替证据做价值判断 | 删除或用结果证明重要性 |
| 毫无疑问、众所周知 | 绝对化且缺少来源 | 删除、限定或引用 |
| 具有重要意义 | 贡献不具体 | 说明改变了哪项认识、方法或决策 |
| 填补空白 | 容易夸大新颖性 | 用可验证的检索结论限定 |
| 系统、全面、深入 | 常作为空泛修饰 | 给出覆盖范围或分析维度 |
| 首先、其次、再次、最后 | 容易形成机械脚手架 | 仅在真实顺序关系中保留 |

## 科学语感

- **给数字和条件，不只给形容词。** 用“提高 28.6%”替代无依据的“显著提高”；用“≥0.10 wt%”替代“较高浓度”。
- **区分证据等级。** “实验显示”“模型预测”“作者推测”和“尚待验证”不能互换。
- **引用动词要精确。** “报告”用于结果，“提出”用于观点或模型，“证明”只用于证据真正排除主要替代解释的情况。
- **保留适用边界。** 数值、机制和比较都应说明材料、条件、时间尺度或测量方法。
- **符号要规范。** 上下标、单位、变量斜体和可逆/不可逆反应符号保持一致。

## 常见 AI 写作痕迹

1. 用“上述分析表明”“综上所述”机械复述上一句。
2. 用“系统的研究”“深入的探讨”“全面的分析”填充而不定义覆盖范围。
3. 在没有真实递进关系时反复使用“不仅……而且……”。
4. 以“为后续研究提供参考”“具有工程指导意义”等套话结束段落。
5. 为追求流畅而加入过多连接词，掩盖证据链断裂。
6. 每段采用相同长度、句式和收束方式，形成模板节奏。

处理原则：先恢复论点、证据和限制条件，再清理句式；不能用语言变化掩盖科学问题。

## 句式偏好

- 主语明确，减少“其”“该”“此”等可能产生歧义的指代。
- 一个句子承载一个主要判断；超过约 40 个汉字时检查能否拆分。
- 主动表达通常比翻译式被动语态更清楚，例如“实验表明”优于“被实验所表明”。
- 相邻句之间明确因果、转折、比较或限定关系，不追求表面平滑。

## 文献处理

- 初稿中的每个关键事实都应有可追踪的作者—年份、编号或 DOI 占位符。
- 多篇文献支持同一事实时，优先选择原始、代表性和方法可比的来源，不机械堆砌。
- 不把综述作者的转述当作原始证据；重要主张应回查原始研究。
- 不替被引作者补充其论文没有明确提出的因果解释或结论。
- 对互相矛盾的结果，比较条件、方法和不确定性，而不是强行合并成单一结论。

## 与 `research-anti-slop.md` 的关系

`research-anti-slop.md` 面向 proposal 的可信度和论证清理；本文件面向中文综述的科学语感、事实密度和引用表达。根据文本类型选择加载，必要时可同时使用。

references/compose-mode.md›

# Compose mode

Use when the user provides a topic, title, vague idea, or research direction and wants a proposal or research plan drafted.

## Contents

- [Overview](#overview)
- [Adaptive intake](#adaptive-intake)
- [Step-by-step](#step-by-step)
- [Step 1: Intake and scope](#step-1-intake-qa--00_scopemd)
- [Steps 2-5: Foundation files](#step-2-build-01_research_canonmd)
- [Steps 6-9: Review, drafting, QA, and export](#step-6-foundation-review)

## Overview

```text
Intake Q&A → scope lock → research canon → evidence table → argument map
→ section contracts → foundation review → section drafting → section QA
→ full proposal QA → export
```

Each step produces a concrete file or decision. Do not skip foundation steps.
Drafting begins only after foundation review passes the stage threshold (foundation_score > 7.5).

---

## Adaptive intake

Default: one question at a time. Switch to grouped questions (3-5 at once) only if the user asks to move faster. Do not ask questions whose answers are already present in the supplied materials or the current session.

### 本子-based intake (special pattern)

When the user is working from an existing 本子 (approved project blueprint) rather than composing from scratch, the intake phase is dominated by the user sharing structured pieces of the 本子 (abstract, research content, methods, innovations, targets). The agent should:

1. **Collect all before building**. If the user says "不要急着开始，先接收信息", do not jump to foundation files while information is still arriving.
2. **Let the user control the sequence**. They know the 本子 structure; they'll share what's relevant in their order.
3. **Acknowledge each piece concisely** — confirm receipt and key implications — but don't synthesize prematurely.
4. **Ask what's still missing** only after the user signals the flow is complete ("还有吗").
5. **Only then** proceed to scope → canon → evidence → argument map.

**Intake checklist by priority:**

| Priority | Must resolve | How |
|---|---|---|
| P0 | text type, target reader, topic/direction, output language, deliverable scope | ask if unknown |
| P1 | core scientific question, existing evidence, required content, forbidden claims, target style | ask if unknown or ambiguous |
| P2 | word count, format requirements, reference template, timeline | ask only if the user volunteers it or the task clearly requires it |

**Rule**: only ask questions whose answers change the writing path. If the user says "write a proposal about corrosion" and you already know from context it's a doctoral research plan for their supervisor, don't ask "what document type" — confirm the assumption: "I assume this is a doctoral research proposal for your supervisor, in Chinese, covering the first part of the project. Correct?"

---

## Step-by-step

### Step 1: Intake Q&A → `00_scope.md`

- **Match proposal depth to project timeline**: A proposal for work starting 1+ years out should be direction-level (框架对、逻辑通), not execution-level (操作级细节). Detailed methods belong in pre-experiment planning, not the proposal.
- **When user says "只是写一个大致的proposal，并不是具体的执行书"** — lock scope to direction-level. Avoid over-specifying equipment, SOPs, or safety protocols that belong in lab manuals.

**Input**: the user's topic or idea, plus relevant supplied materials and current-session context.

**Output**: `00_scope.md` filled with at minimum: project slug, mode, text type, target reader, language, deliverable scope.

**Pitfalls**:
- Don't ask P2 questions during intake unless the user brings them up. Scope first, details later.
- Don't treat intake as a questionnaire. One clarifying question that narrows a real ambiguity is worth ten checklist items.
- If the user says "先不管这些，直接开始写", lock scope with reasonable defaults from the available context and move to Step 2.

### Step 2: Build `01_research_canon.md`

**Input**: `00_scope.md`, user-provided domain context, and traceable literature from the available literature-search workflow.

**Output**: `01_research_canon.md` with at minimum:

| Section | Minimum content |
|---|---|
| Literature facts | ≥ 3 statements, each with source (author-year or DOI) |
| Experimental facts | ≥ 2 statements about what is known or measured (including user-provided prior work) |
| Thermodynamic/model facts | if applicable; flag as "model output, needs experimental verification" |
| Supervisor constraints | direct quotes or paraphrases of supervisor requirements |
| Terminology definitions | key terms that must be used consistently |
| Forbidden claims | claims that the text must not make (e.g., "cannot claim treatment A is effective without target-condition evidence") |
| Unresolved claims | facts that are debated or unverified; writing may note them but not resolve them |

**Pitfalls**:
- Don't derive canon from "common knowledge". Every entry must trace to a source.
- Don't treat literature conclusions as canon if they conflict. Mark as "unresolved" with both sides.
- Don't treat simulation output as experimental fact. Flag model data explicitly.
- Canon is a boundary file. Writing cannot silently alter it. If new evidence emerges during drafting, update canon first.

### Step 3: Build `02_evidence_table.md`

**Input**: `01_research_canon.md`, literature sources, and user-provided prior data.

**Output**: `02_evidence_table.md` — a table mapping claims to evidence.

Each row: `claim | evidence/source | strength | usable section | risk | status`

Strength values: `evidence-backed` / `plausible-inference` / `hypothesis` / `unsupported`

Status: same as strength, but updated as drafting progresses.

**Minimum**: ≥ 5 rows covering the core scientific claims the proposal will make.

**Pitfalls**:
- Don't inflate hypothesis to evidence-backed. "Component A may react with component B" remains a hypothesis until the reaction is supported under the target conditions.
- If a claim has no usable evidence, mark it `unsupported`. Don't hide it by omission. The argument map will decide whether to include, downgrade, or request evidence.
- Evidence that is "obvious from the literature" still needs a citation.

### Step 4: Build `03_argument_map.md`

**Input**: `01_research_canon.md`, `02_evidence_table.md`.

**Output**: `03_argument_map.md` with:

| Section | Content |
|---|---|
| Scientific tension | what is known, what is unknown, why the gap matters |
| Central research question | one sentence; must be answerable by the proposed work |
| Central thesis | one sentence; the answer you expect (or the hypothesis you test) |
| Supporting arguments | 2-4 arguments, each with: claim, evidence (from evidence table), limitation |
| Counterarguments | alternative explanations or opposing views; how the proposal addresses or acknowledges them |
| Final move | what the reader should conclude after reading the proposal |

**Pitfalls**:
- Don't write arguments that can't be supported by the evidence table. If you discover a gap, go back to Step 3 and add/flag evidence.
- A weak central research question ("study the behavior of...") produces a weak argument map. Falsifiable questions ("does treatment A reduce the target impurity more effectively than treatment B under matched conditions?") produce strong maps.
- Counterarguments are not weaknesses. A proposal that states how an uncontrolled variable could invalidate the preferred route is stronger than one that ignores it.

### Step 5: Build `04_section_contracts.md`

**Input**: `00_scope.md`, `03_argument_map.md`, default proposal structure.

**Output**: One contract per section. Each contract:

```
## Section: [name]
- Purpose: what this section must accomplish in the overall argument
- Inputs: which canon/evidence/argument items feed into this section
- Allowed claims: claims this section may make (from evidence table)
- Forbidden claims: claims this section must not make (from canon forbidden list + scope boundary)
- Required evidence: evidence that must appear in this section
- Validation checklist: 2-4 checks to verify the section does its job
```

**Default proposal sections** (adjustable to supervisor/school requirements):

1. 研究背景与意义
2. 国内外研究现状
3. 科学问题与研究目标
4. 研究内容
5. 技术路线与实验方法
6. 创新点
7. 可行性分析
8. 研究计划与预期成果

**Pitfalls**:
- Don't let "研究背景" contract allow claims that belong in "研究现状". Background = why this domain matters; literature review = what others did and what gap remains.
- Innovation section contract must forbid: "本研究具有重要的理论和工程意义". Allowed: specific, testable contribution statements.
- If the proposal is partial-stage (e.g., Part 1 only), load `references/partial-proposal-scope.md` and add a scope-boundary constraint to every section contract.

### Step 6: Foundation review

**Input**: all 5 foundation files.

**Process**: run professor with 1-2 specialists (doctoral proposal reviewer + domain expert). Score foundations using evaluation rubric. If `foundation_score < 7.5`, return to the weakest foundation file and fix it before drafting.

**Output**: professor review notes in `qa_logs/foundation_review.md`, updated foundation files if issues found.

**Gate**: do not begin drafting until `foundation_score > 7.5`.

### Step 7: Draft section by section

**Input**: all foundation files, section contracts.

**Process**: draft one section at a time. For each section:
1. Read the section contract.
2. Extract the allowed claims and required evidence.
3. Draft the section text, citing evidence as you go.
4. Run section QA (score via evaluation rubric; target: `section_score > 6.5`).
5. If score < 6.5, fix the section before moving on. Do not accumulate broken sections.

**Pitfalls**:
- First draft aims for forward progress, not perfection. A 6.5 section is keepable; don't polish to 9.0 before writing the next section.
- Don't cross-contaminate sections. If "研究内容" starts describing background, stop and check the section contract.
- Evidence that appears in the draft but not in the evidence table must be added to the evidence table. Don't let draft text become an ungoverned source of claims.

### Step 8: Full proposal QA

**Input**: completed draft, all foundation files.

**Process**: run full evaluation rubric on the complete proposal. Score all 8 dimensions. Record in `qa_logs/proposal_qa.md`.

**Gate**: `proposal_score > 7.0` for supervisor-facing; `> 8.0` for final polish.

If score < 7.0: identify the weakest 1-2 dimensions, return to the relevant foundation file or section, fix, re-draft affected sections, re-score.

### Step 9: Export

**Input**: QA-passed draft, `00_scope.md`.

**Process**: produce `exports/proposal_final.md` (archive) and `exports/proposal_final.docx` (submission). Run pre-delivery checks: no unresolved TODOs, no unsupported claims masquerading as facts, citation placeholders resolved, figure/table numbering consistent, version+date clear.

**Pitfalls**:
- Don't skip the .docx export. .md is for version control; .docx is what the supervisor reads.
- If the proposal is partial-stage, the export filename should reflect that (e.g., `part1_xxx.md` not `proposal_final.md`).

references/evaluation-rubric.md›

# Evaluation rubric

Score each dimension 0-10. Anchors below are for Chinese doctoral proposals in materials/chemistry/engineering domains.

## Contents

- [Dimensions 1-4: Problem, tension, evidence, and logic](#1-研究问题清晰度--does-the-text-clearly-state-the-problem)
- [Dimensions 5-8: Feasibility, novelty, risk, and language](#5-方法可行性--concrete-enough-to-reproduce-or-challenge)
- [Scoring procedure](#scoring-procedure)
- [Thresholds](#thresholds)

## 1. 研究问题清晰度 — Does the text clearly state the problem?

| Score | Anchor |
|---|---|
| 3 | No identifiable research question; topic described in general terms. |
| 5 | Question implied but buried in narrative; reader must extract it. |
| 7 | Question stated explicitly, but embedded in background section rather than standing alone. |
| 9 | Question stated in a dedicated section; precise and falsifiable. |

**Common fix**: Extract the core question into a standalone "科学问题" paragraph or section.

## 2. 科学张力 — Known → unknown → why the gap matters

| Score | Anchor |
|---|---|
| 3 | Literature listed without synthesis; no gap articulated. |
| 5 | Gap stated but not motivated — "few studies have..." without explaining why that matters. |
| 7 | Gap clearly stated with partial motivation; the consequence of filling the gap is implied but not explicit. |
| 9 | Gap is a genuine contradiction or engineering constraint (e.g., improving one target property invalidates the established control route). Reader can see why the tension matters. |

## 3. 证据匹配 — Claims backed, hypotheses flagged

| Score | Anchor |
|---|---|
| 3 | Claims presented as facts without sources; no distinction between literature, model output, and speculation. |
| 5 | Sources cited but precision overstated — model estimates presented with 3 significant figures, hypotheses phrased as findings. |
| 7 | Clear distinction between literature findings, model estimates, and hypotheses. Boundary sentences flag when model data needs experimental validation. Formal references present. |
| 9 | Every claim traceable to source type; uncertainty quantified or explicitly bounded; "we hypothesize" vs "we found" clearly separated. |

**Red flags**: simulation/model results reported to 3+ significant figures; figure data cited without acknowledging it needs experimental verification.

## 4. 逻辑链 — Background → gap → question → objectives → methods → outcomes

| Score | Anchor |
|---|---|
| 3 | Sections disconnected; methods don't trace back to objectives; outcomes don't answer the question. |
| 5 | Chain mostly connected but one or more links are weak — e.g., objectives list items that don't appear in methods. |
| 7 | Chain is coherent end-to-end. At least one sub-chain is exceptionally tight (e.g., a specific problem → a specific method designed to address it). |
| 9 | Every objective maps to a method, every method to an expected outcome. No orphaned objectives or untethered methods. |

## 5. 方法可行性 — Concrete enough to reproduce or challenge

| Score | Anchor |
|---|---|
| 3 | Methods described in generic terms ("characterize the corrosion behavior") with no specifics. |
| 5 | Some specifics present (composition, temperature ranges) but gaps in environmental control, sampling protocol, or measurement parameters. |
| 7 | Variables, controls, materials, atmosphere, sample preparation, and characterization methods are concrete. One or two operational details remain to be settled by pre-experiments — flagged, not hidden. |
| 9 | Another researcher could reproduce the experiment from this description. Pre-experiment uncertainties listed with initial reference values from literature. |

**Common pitfall**: "take sample, then add metal coupon, then re-heat" — if atmosphere control during the intermediate step is not described, flag it.

## 6. 创新性 — Specific contribution, not slogan

| Score | Anchor |
|---|---|
| 3 | "First study of..." with no explanation of why being first matters. Innovation as label, not argument. |
| 5 | Contribution direction stated but vague — "systematic study" without specifying what new knowledge is expected. |
| 7 | Contribution is specific and motivated (e.g., "establishing whether treatment A can replace treatment B under the target operating conditions"). Innovation is implicit in the argument chain rather than listed as bullet points. |
| 9 | Contribution is explicit, specific, and novel enough that a reviewer can immediately place it relative to the literature. |

## 7. 风险边界 — Uncertainty, alternatives, and limitations acknowledged

| Score | Anchor |
|---|---|
| 3 | All outcomes presented as certain; no discussion of what could go wrong. |
| 5 | Generic "further research needed" placeholder. |
| 7 | Conditional outcome logic present ("if X, then Y; if not, then Z"). Backup paths identified for key uncertain steps. |
| 9 | Decision tree for major uncertainties; explicit "if all candidates fail" fallback; abnormal-condition handling protocol described. |

## 8. 语言质量 — Clear, non-template, free of unsupported intensifiers

| Score | Anchor |
|---|---|
| 3 | Dense anti-patterns: 具有重要意义, 填补空白, 显著, 系统, 首先/其次/再次 scaffolding, background too broad. |
| 5 | Some anti-patterns present; sentences overly long (>100 characters); expected-outcomes section bloated relative to methods. |
| 7 | Minimal anti-patterns. Literature citations contextualized, not listed. Long sentences exist but are readable. |
| 9 | No detectable anti-patterns. Prose is efficient, precise, and domain-appropriate. |

## Scoring procedure

1. Read the full text first.
2. Scan for the specific anti-patterns listed in `research-anti-slop.md` (for dimension 8).
3. Score each dimension independently — do not let one dimension's problems bleed into another.
4. For each score below 7, write one sentence explaining the specific problem. Do not use the anchor descriptions verbatim; cite the text.
5. Report scores + problems, then recommend: restructure / internal draft / supervisor-facing / final polish.

## Thresholds

```text
< 6.0    不可交付，必须重构
6.0-7.0  内部草稿
7.0-8.0  可给导师看
> 8.0    正式版本打磨
```

Stage thresholds:

```text
foundation_score > 7.5 before formal drafting
section_score > 6.5 to keep a draft section
proposal_score > 7.0 for supervisor-facing draft
proposal_score > 8.0 for final polish
```

references/export-archive.md›

# Export and archive

Formal export must create two files:

```text
exports/proposal_final.md     # archive / versioning / future reuse
exports/proposal_final.docx   # submission / supervisor circulation
```

Optional export:

```text
exports/proposal_final.pdf
```

**.docx 必须用 python-docx 脚本生成，禁止用 pandoc**。pandoc 输出的 .docx 格式粗糙（标题蓝色、无中文字体、无段落格式），不可直接交付。使用 `scripts/build_proposal_docx.py`，该脚本实现以下格式：Times New Roman 12pt + 宋体，Heading 黑体或宋体加粗黑色，1.5 倍行距，四边 1 英寸页边距，表格 10pt 带网格。Load `pdf` only when PDF is requested.

## Pre-delivery checks

- No unresolved TODOs
- No unsupported claims presented as facts
- Citation placeholders cleared or explicitly marked
- Figure/table numbering consistent
- Version name and date clear
- Target threshold reached or remaining risks reported

## docx 格式要求

pandoc 默认输出格式粗糙，正式提交版需用 python-docx 生成：
- 标题：居中、Times New Roman + 宋体、18pt 加粗、黑色
- Heading 1/2/3：Times New Roman + 宋体、16/14/12pt、加粗、黑色
- 正文：Times New Roman + 宋体、12pt、1.5 倍行距、无首行缩进（西文论文风格）
- 页边距：四边 1 英寸
- 表格：10pt、Table Grid 样式
- 代码块：Consolas 9pt

参考脚本：`scripts/build_proposal_docx.py`（解析 markdown → 格式化 docx）

## Archive rule

Before writing to an external archive, vault, or synced folder, ask for explicit approval:

```text
是否归档到 <archive-root>/researchwrite/<project-slug>/？
```

Keep external archival outside the default pipeline unless the user explicitly requests it.

references/foundation-files.md›

# Foundation files

## 00_scope.md

Records text type, target reader, language, deliverable scope, version target, constraints, vault access, and archive intent.

## 01_research_canon.md

Hard facts and boundaries. Include literature facts, experimental facts, thermodynamic/model facts, supervisor constraints, terminology definitions, forbidden claims, and unresolved claims.

Rule: writing cannot silently alter canon.

## 02_evidence_table.md

Claim map with fields:

```text
claim | evidence/source | strength | usable section | risk | status
```

Status values:

```text
evidence-backed
plausible-inference
hypothesis
unsupported
```

## 03_argument_map.md

Scientific tension, central research question, central thesis, supporting arguments, counterarguments, limitations, and final move.

## 04_section_contracts.md

For each section: purpose, inputs, allowed claims, forbidden claims, required evidence, validation checklist.

## 05_style_guide.md

Language, terminology, forbidden expressions, supervisor preference, and stance: conservative / innovation-forward / engineering-feasibility / scientific-question-driven.

references/gpt-handoff-revision-brief.md›

# GPT 改稿交接模式

当用户使用外部 LLM（GPT/Codex 等）进行 proposal 修订时，用本模板生成结构化修改指令。

## 使用时机

- 用户说“让 GPT 去改”或“交给 Codex”
- proposal 审查完成后需要将修改点整理为独立指令文件
- 需要向外部 LLM 提供：任务书 + 原稿 + 修改指令 三件套

## 指令文件结构

```
# 项目名 — 修订要点（给 GPT 的修改指令）
> 基于 [日期] 多轮讨论 + professor 审查结论

## 一、核心定位调整
[一句话新定位，原定位 → 新定位]

## 二–N、逐条修改要点
[按 P0/P1/P2 优先级排序]
每条包含：原稿问题 → 改为 → 具体位置

## 末、最终主线句
[替换原稿的定位段]
```

## 原则

- **P0 先于 P1**：GPT 按优先级顺序修改
- **给出具体位置**：指明 § 编号和原稿表述，不让 GPT 自己找
- **给出替换文本**：不确定的地方写方向，确定的地方写原句
- **标注"不动"**：明确告诉 GPT 哪些结构和表述保持不变
- **三件套缺一不可**：任务书摘要 + 原稿 + 修改指令

## 文件命名

`revision_briefs/GPT修改指令_YYYY-MM-DD.md`

## 交付检查

- 修订指令不依赖当前会话中的隐含上下文。
- 所有 P0/P1 项都有原稿位置和验收标准。
- 任务书摘要、原稿和修改指令中的术语与版本保持一致。

references/hybrid-mode.md›

# Hybrid mode

Use when the user has an existing draft but also wants expansion, gap-filling, restructuring, or new sections.

Hybrid is not a third independent workflow. It composes revise + compose.

## Flow

```text
revise existing draft
  ↓
identify gaps
  ↓
compose missing sections
  ↓
merge
  ↓
full QA
```

## Rules

- Evaluate existing text before adding new text.
- Every gap becomes a section contract or evidence-table item.
- New content must update canon/evidence when it introduces new claims.
- Merged drafts must run full proposal QA.

references/partial-proposal-scope.md›

# Partial proposal scope control

Use when the user is writing only one part or stage of a doctoral research plan, not the full proposal.

## Rule

Do not force a partial-stage draft into a full doctoral-plan structure. First lock the stage boundary.

## Scope-lock questions/checks

1. Which part/stage is being written now?
2. Which later stages are intentionally deferred?
3. What missing information blocks later-stage writing? Examples: lab visit, supervisor decision, equipment availability, procurement, platform design.
4. Should deferred content appear only as “后续研究方向” rather than as current objectives or methods?

## Generic first-stage example

If the current text covers only preliminary screening and offline validation:

- Current scope: candidate selection, controlled preparation or treatment, route comparison, and a bounded verification experiment.
- Deferred scope: online monitoring, platform integration, scale-up engineering, and operating protocols that depend on equipment not yet confirmed.
- Reason: later stages require facility, procurement, or supervisor decisions that are outside the current evidence boundary.
- Writing consequence: retain deferred work as a brief follow-on direction; do not expand it into current-stage objectives, deliverables, or methods.

## Common pitfall

Bad: “This draft lacks a complete doctoral-plan platform/electrochemistry design, so expand it now.”

Good: “This is a first-stage plan; evaluate whether the first-stage offline loop is coherent, executable, and sufficient to justify later platform work.”

references/professor-dispatch.md›

# Professor dispatch

`professor` is a dynamic specialist generator, not a fixed expert pool. Select reviewers from the current failure mode instead of reusing a generic panel.

## Contents

- [Dispatch contract](#dispatch-contract)
- [Expert count](#expert-count)
- [Selection and permanence rules](#selection-and-permanence-rules)
- [Example 1: Focused claim review](#example-1-focused-claim-review)
- [Example 2: Foundation review](#example-2-foundation-review)
- [Example 3: Language-only work](#example-3-language-only-work)
- [Example 4: Full-proposal QA](#example-4-full-proposal-qa)

## Dispatch contract

Provide:

```text
task_context
current_mode
text_type
research_domain
current_failure_mode
needed_review_depth
canon/evidence/draft summary
```

Request:

```text
selected_experts
expert_reviews
conflict_summary
recommendation
permanence_candidate
```

Every expert review must distinguish:

- evidence-backed findings;
- plausible but unverified interpretations;
- missing information that requires author input;
- recommendations that would change scope or scientific commitments.

## Expert count

- Default: 1-2 specialists.
- Complex proposal: 2-4 specialists.
- Final review or major direction decision: up to 5 specialists.
- More than 5 requires an explicit rationale.

When independent review capability is available, run non-overlapping specialists in parallel. Otherwise, perform clearly separated expert passes and preserve each pass in the QA log.

## Selection and permanence rules

Select specialist classes that map directly to the failure mode. Examples include a domain-mechanism expert, methods expert, statistics expert, feasibility reviewer, doctoral-proposal reviewer, academic-style reviewer, adversarial reviewer, or supervisor-perspective reviewer.

Do not request a broad domain expert when the failure is narrow. A vague mechanistic claim needs a mechanism specialist; an overloaded work plan needs a feasibility reviewer.

If the same specialist class is invoked at least three times, or the user explicitly asks to retain it, propose creating a reusable long-term reviewer. Do not create one without approval.

## Example 1: Focused claim review

**Context**: Revise mode identified a mechanism claim that uses “may affect” without specifying a plausible pathway or the evidence supporting it.

**Dispatch input**:

```text
task_context: "Revising the background section of a materials proposal."
current_mode: revise
text_type: doctoral_proposal
research_domain: high-temperature materials chemistry
current_failure_mode: >
  The draft says additive A may change degradation pathways, but it does not
  identify a reaction, phase, transport process, or supporting source.
needed_review_depth: medium
canon/evidence/draft summary:
  - Study 1 reports a change in product phase under condition X.
  - Study 2 reports suppression of a precursor reaction under condition Y.
  - Neither study directly measures the proposed pathway under the target condition.
```

**Expected response**:

```text
selected_experts:
  - reaction-mechanism specialist
  - evidence-calibration reviewer
expert_reviews: [specific assessment from each reviewer]
conflict_summary: [agreement or the exact disputed point]
recommendation:
  - retain claims directly supported by the cited studies
  - label the target-condition pathway as a hypothesis
  - state which measurement would discriminate competing explanations
permanence_candidate: none
```

## Example 2: Foundation review

**Context**: Compose mode has produced the canon, evidence table, and argument map. Review is required before section contracts.

```text
task_context: "Review foundation files for Part 1 of a materials-science project."
current_mode: compose
text_type: doctoral_proposal_foundation
research_domain: materials processing and durability
current_failure_mode: >
  The argument map may overemphasize a performance benefit while treating a
  route-limiting compatibility constraint as a secondary issue.
needed_review_depth: medium
canon/evidence/draft summary:
  - 7 literature facts
  - 2 supervisor constraints
  - 12 claim-evidence mappings
  - 1 central question, 3 supporting arguments, 1 counterargument
```

Select a proposal-structure reviewer and a domain feasibility expert. Ask whether the central tension is evidence-backed, whether the question can be answered by the proposed methods, and whether any supporting argument must be downgraded before drafting.

## Example 3: Language-only work

If the user explicitly requests language-only review and the diagnosis finds no content-level risk, skip professor dispatch. Load `references/research-anti-slop.md`, run the language scan, and produce a focused revision brief. Do not manufacture a scientific review stage when it cannot change the result.

## Example 4: Full-proposal QA

For a completed proposal, separate technical and argument reviews:

```text
Specialist A: domain methods and feasibility
  focus: scientific assumptions, controls, operating window, failure criteria,
         reproducibility, evidence gaps, and fallback routes

Specialist B: proposal structure and doctoral fit
  focus: argument chain, testable objectives, workload, risk boundaries,
         concrete novelty, section integrity, and language quality

Both receive:
  - scope and task brief
  - research canon and evidence table
  - complete draft
  - section contracts

Both return:
  - P0/P1/P2 findings with locations
  - dimension scores with reasons
  - the single most consequential revision
```

Reconcile the reviews explicitly. If they conflict, identify whether the disagreement comes from evidence interpretation, feasibility assumptions, or scope. The author or a qualified domain owner retains final scientific judgment.

references/project-structure.md›

# Project structure

Default working directory:

```text
<outputs>/researchwrite/<project-slug>/
```

Archive only with approval:

```text
<archive-root>/researchwrite/<project-slug>/
```

Do not write to any external archive, vault, or synced folder unless explicitly requested.

## Files

```text
00_scope.md
01_research_canon.md
02_evidence_table.md
03_argument_map.md
04_section_contracts.md
05_style_guide.md
state.json

sources/
  user_materials/
  literature/
  data/

drafts/
  proposal_v0.md
  proposal_v1.md
  sections/

revision_briefs/
qa_logs/
exports/
```

## state.json minimum

```json
{
  "project": "",
  "mode": "compose|revise|hybrid",
  "text_type": "doctoral_proposal",
  "language": "zh|en|mixed",
  "target_reader": "",
  "current_round": 0,
  "scores": [],
  "technical_debts": [],
  "status": "intake|foundation|drafting|revision|export"
}
```

references/ref-renumbering-cascade.md›

# Reference Renumbering in docx Body Text

## Problem

When removing or reordering references in a review paper, both the reference list AND all in-text citations must be renumbered. Running text replacement in cascade (high→low) causes citation numbers to collapse into each other.

## Correct Order

1. **Fix body citations FIRST** (before modifying reference list)
2. **Process LOW to HIGH** when iterating over remap keys
3. **Skip reference paragraphs** during body citation replacement to avoid double-processing

## Python Pattern

```python
# remap: dict of {old_number: new_number_or_None_if_deleted}

# STEP 1: Fix body citations only (before ref list modification)
for p in doc.paragraphs:
    if p is in reference section:  # skip!
        continue
    for run in p.runs:
        for old_n in sorted(remap.keys()):  # 1,2,3,... low→high
            new_n = remap[old_n]
            if new_n is None and old_n == DELETED:
                run.text = run.text.replace(f'[{old_n}]', f'[{NEIGHBOR}]')
            elif new_n is not None and new_n != old_n:
                run.text = run.text.replace(f'[{old_n}]', f'[{new_n}]')

# STEP 2: Delete old ref section
# STEP 3: Append new ref list with correct numbers
```

## Why High→Low Fails

Processing [46]→[45], then [45]→[44], ... causes newly created [45]s from step 1 to be incorrectly re-replaced to [44] by step 2. The cascade collapses all citations in the range to the lowest number.

## Verification

```python
gaps = [n for n in range(1, total+1) if n not in ref_list_numbers]
dupes = set(n for n in ref_list_numbers if ref_list_numbers.count(n) > 1)
orphans = body_citation_numbers - set(range(1, total+1))
assert gaps == [] and dupes == set() and orphans == set()
```

references/research-anti-slop.md›

# Research anti-slop

Chinese proposal cleanup focused on research credibility, not generic prettiness.

## Empty significance

Flag: 具有重要意义, 填补空白, 提供理论基础, 具有广阔应用前景.

Fix: specify contribution to which mechanism, method, material system, measurement, or decision.

## Unsupported intensifiers

Flag when unsupported: 显著, 全面, 系统, 深入, 揭示机理, 有效提升.

Fix: add evidence or downgrade the strength.

## Mechanical structure

Flag dense use of: 首先/其次/再次/最后, 在此基础上, 进一步地, 本文拟.

Fix: keep necessary logical transitions; remove formulaic scaffolding.

## Structural anti-patterns

- Background too broad and not serving the research question
- Literature list without synthesis
- Innovation detached from methods
- Conclusion stronger than evidence
- Too many objectives without one main line
- Discussion repeats results rather than explaining implications and limits

Fix structural problems by returning to `03_argument_map.md` or `04_section_contracts.md`, not by sentence polishing.

references/review-critique-methodology.md›

# Review Critique Methodology

## When to Load

Use this reference when the user asks you to **evaluate** an existing review/survey paper for quality — not to write one, but to assess critical depth, narrative coherence, analytical voice, and research gap insight.

Load alongside the base `researchwrite` SKILL.md. This reference provides the evaluation framework; the base SKILL provides the research context (domain defaults, project structure, etc.).

## Contents

- [6-Dimension Evaluation Framework](#6-dimension-evaluation-framework)
- [Scoring Scale](#scoring-scale)
- [Paragraph-Level Citation Format](#paragraph-level-citation-format)
- [Output Format](#output-format)
- [Document Discovery and Reading](#document-discovery-and-reading)
- [Pitfalls](#pitfalls)

## 6-Dimension Evaluation Framework

Score each dimension on a 1-10 scale, then report per-dimension scores alongside an overall score. Each dimension has specific signals to look for.

### D1: Synthesis vs Literature Stacking

**What to check**:
- Does the review just list findings ("Person A found X; Person B found Y; Person C found Z") or does it build a conceptual framework?
- Are contradictions between studies identified and discussed? Or papered over?
- Does the author propose their own organization of the field (a taxonomy, a phase model, a paradigm narrative)?
- **Red flag**: Sections that are pure reference-by-reference recitation with zero connective analysis.
- **Positive signal**: An explicit meta-narrative — "School A vs School B", "Phase 1 → Phase 2 paradigm shift" — constructed by the author, not borrowed from a single cited paper.

### D2: Causal Chain Coherence

**What to check**:
- Trace the logical chain from fundamentals to applied outcomes. For corrosion/materials reviews, the canonical chain is: `melt chemistry → oxide film formation → failure mechanisms → control strategies`.
- Are all links present? If "failure" is described only implicitly within "formation", that's a missing link.
- Is the chain qualitative or quantitative? Are critical thresholds, transition criteria, or phase boundaries given?
- **Red flag**: The chain is assumed but never explicitly traced. Reader must infer the connections.
- **Positive signal**: A single explicit equation or block diagram connecting all stages.

### D3: Classification Systems (e.g., Failure Modes)

**What to check**:
- Do the proposed categories emerge naturally from the data/mechanisms? Or are they forced / artificial?
- Within each category: are conditions, thresholds, and sub-mechanisms analyzed? Or just listed?
- Do categories have clear boundaries, or do they overlap?
- Are interactions between categories discussed (e.g., "does mechanism A accelerate mechanism B?")?
- **Red flag**: Categories are enumerated but each gets only a sentence. No individual analysis.
- **Red flag**: "Four failure modes" claimed but the text only discusses one or two in any depth.

### D4: Author's Analytical Voice

**What to check**:
- Can you find sentences where the author makes a **judgment** (not just reports)? ("This evidence is weak because...", "The field overlooks...", "This claim exceeds what the data support.")
- Does the author take positions on contested issues? Or stay safely neutral?
- Are limitations of cited works called out, or just described neutrally?
- **Red flag**: The review reads like an annotated bibliography — paragraph after paragraph of "X reported Y. Z reported W." with zero authorial framing.
- **Positive signal**: The author names what is missing, what is overclaimed, or what the field is getting wrong — then backs it up.

### D5: Research Gaps Discussion

**What to check**:
- Is the gaps section **structured** (organized by dependency, priority, or sub-field)? Or just "more research is needed"?
- Are gaps **derived from the review's own analysis**? Or generic talking points?
- Are gaps **prioritized**? (Which are most urgent? Which are prerequisites for others?)
- Are concrete **research paths or roadmaps** proposed?
- **Positive signal**: Gaps organized by dependency hierarchy (hardware → methodology → application → engineering), with explicit priority assessment.

### D6: Overstatement and Over-Extrapolation

**What to check**:
- Absolute or superlative language: "most", "best", "first", "only", "always", "never", "唯一", "最", "首次"
- Claims that exceed the evidence base cited (e.g., one study positioned as representing the whole field)
- Overly precise quantitative claims without qualifiers: error bars, condition ranges, applicability limits
- **Red flag**: Author's narrative commitment drives stronger claims than the data support.
- **Positive signal**: Author explicitly qualifies claims with conditions, ranges, and confidence levels.

## Scoring Scale

| Score | Meaning |
|:----:|---------|
| 9-10 | Field-defining synthesis. Minor flaws at most. |
| 7-8 | Strong synthesis with clear authorial voice. Some sections weaker. |
| 5-6 | Adequate — reports literature accurately but adds limited analysis. |
| 3-4 | Mostly literature stacking; author absent from the narrative. |
| 1-2 | Annotated bibliography or error-ridden. |

## Paragraph-Level Citation Format

Always cite specific line ranges or section numbers. Use this format:

> **Section X (lines M-N)**: [quote or paraphrase of the problem passage]
> **Problem**: [specific analytical issue]
> **What's missing / what's weak**: [what a critic would demand]

**Bad**: "Section 3 is weak. The discussion is shallow."
**Good**: "Section 3.1.4 (lines 1341-1361): Describes the bilayer oxide structure but presents it as settled fact. Does not address whether higher-resolution characterization (APT, HRTEM) has revealed finer structure, or whether contradictory reports exist. Reads as uncritical recitation of a single established model."

## Output Format

Provide critique as:

1. **Overall Score**: X/10 (note the document title and scope)
2. **Individual Dimension Scores**: Table:

   | Dimension | Score | Key Issue |
   |:----------|:-----:|:----------|
   | D1: Synthesis vs Stacking | 7.5 | ... |
   | D2: Causal Chain | 7.0 | ... |
   | D3: Classifications | 3.5 | ... |
   | D4: Author Voice | 6.0 | ... |
   | D5: Research Gaps | 8.5 | ... |
   | D6: Overstatement | 7.0 | ... |
   | **Overall** | **6.5** | |

3. **Section-by-Section Issues**: Paragraph-level citations with specific line references
4. **Constructive Recommendations**: Actionable fixes for the author

## Document Discovery and Reading

When the document is not directly attached, search only user-authorized sources and locations:

1. Search the current workspace by exact and partial title, then by distinctive keywords.
2. Search connected document repositories or reference managers when the user placed them in scope.
3. Compare duplicate candidates by modification date, version label, and content rather than filename alone.
4. Handle `.md`, `.docx`, and `.pdf` with format-appropriate readers that preserve headings, tables, and page or line references.
5. Scan the table of contents before reading a long document. Target the relevant sections, but preserve enough surrounding context to assess the full argument.
6. Record the exact file and version used for the critique.

## Pitfalls

- **The title on the file may not match the user's title exactly.** The actual review may have a broader scope than what the user asks about. Focus on the relevant sections.
- **Don't skip the TOC scan on long documents.** 8000-line reviews require targeted reading.
- **Don't confuse "has an opinion" with "has rigorous analysis".** A strong authorial voice is good, but only if backed by evidence cited in the review.
- **Don't give uniformly high scores** — identify specific strengths AND weaknesses. A credible critique shows nuance.
- **Don't stop at the first duplicate.** Confirm which version is authoritative before critiquing it.
- **Preserve layout-dependent evidence.** Tables, captions, footnotes, and page placement may change the interpretation of `.docx` and `.pdf` files.
- **Watch for implicit failure-mode classification.** A review may discuss several mechanisms without defining their categories, boundaries, or interactions. This is itself a criticism worth noting.

references/review-paper-framework.md›

# Review Paper Framework Design — Gap-Driven Approach

Use this reference to design a review or survey paper from a research topic. It covers pre-writing framework design; use `compose-mode.md` after the framework is approved and evidence has been assembled.

## Contents

- [Phase 1: Literature landscape](#phase-1-literature-landscape)
- [Phase 2: Gap identification](#phase-2-gap-identification)
- [Phase 3: Targeted gap filling](#phase-3-targeted-gap-filling)
- [Phase 4: Coverage assessment](#phase-4-coverage-assessment)
- [Phase 5: Causal-chain narrative](#phase-5-causal-chain-narrative)
- [Phase 6: Section contracts](#phase-6-section-contracts)
- [Phase 7: Default structure](#phase-7-default-structure)
- [Phase 8: Figure strategy](#phase-8-figure-strategy)
- [Phase 9: Chinese review style](#phase-9-chinese-review-style)
- [Phase 10: Table-as-figure substitution](#phase-10-table-as-figure-substitution)
- [Pitfalls](#pitfalls)

## Phase 1: Literature landscape

Search multiple independent source classes:

| Source class | Purpose |
|---|---|
| User-provided corpus and project notes | Recover prior decisions, terminology, and curated references |
| Reference manager or institutional library | Find stored papers and verified metadata |
| Scholarly databases and publisher search | Expand beyond the local collection |
| Full text | Verify methods, evidence, limitations, figures, and exact claims |

When available, route broad discovery and citation verification through `nature-academic-search`, and lawful full-text retrieval through `nature-downloader`. Run independent source searches in parallel when permitted, then deduplicate by DOI, title, and study identity.

Record every included source with a stable identifier and the specific review question it supports. Do not treat search-result snippets as evidence.

## Phase 2: Gap identification

Enumerate gaps only after the first landscape pass. Each gap must be:

1. a specific question the review can address;
2. mapped to existing and missing evidence;
3. scored for importance to the review narrative;
4. classified as a knowledge, measurement, comparison, or translation gap.

Example:

```text
Gap 1: Which quantitative criterion separates stable from unstable operation?
Gap 2: Which variables explain disagreement between short- and long-duration studies?
Gap 3: Are reported mechanism classes mutually exclusive or interacting?
Gap 4: Which laboratory measurements predict application-scale performance?
```

## Phase 3: Targeted gap filling

For every gap, design searches using exact mechanisms, measurements, conditions, competing terminology, and key authors. Search backward through references and forward through citing papers for the most important studies.

If a gap remains after a documented search, label it as a candidate field-level gap and report the search boundary. Absence of retrieval is not, by itself, proof that no literature exists.

## Phase 4: Coverage assessment

Count and classify the literature before fixing the section architecture. Report coverage by:

- mechanism or theme;
- evidence type and method;
- operating condition or population;
- publication period;
- primary study versus review;
- directly relevant versus contextual.

There is no universal minimum reference count. A broad review generally needs more coverage than a narrowly framed critical review. Use the target venue and the nearest high-quality reviews as comparators, but judge readiness from coverage of the argument and major counterevidence rather than raw count.

## Phase 5: Causal-chain narrative

Do not organize the paper by research group or citation order. Prefer mechanism, dependency, or decision level.

Build a chain such as:

```text
Boundary conditions → underlying process → measurable state
→ failure or outcome → intervention → application consequence
```

Every major section should map to one link or one well-defined comparison across links. Missing links become explicit gaps rather than silent transitions.

## Phase 6: Section contracts

For each section define:

- **Purpose**: the question the section answers;
- **Inputs**: the evidence and prior sections it depends on;
- **Allowed claims**: claims supported within this section;
- **Forbidden claims**: claims reserved for another section or unsupported by current evidence;
- **Key references**: the small set of indispensable sources;
- **Validation**: checks that demonstrate synthesis rather than literature stacking.

## Phase 7: Default structure

Adapt this mechanism-led template to the field and venue:

| Section | Role |
|---|---|
| 1. Introduction | Problem framing, contribution, and scope boundary |
| 2. Boundary conditions | Environment, system assumptions, terminology, and evidence limits |
| 3. Formation or operating mechanism | How the target state emerges |
| 4. Outcome or failure classes | Systematic classification with criteria and competing explanations |
| 5. Controlling factors | Variables that connect conditions to outcomes |
| 6. Measurement and methodology | How evidence quality and comparability are established |
| 7. Implications and outlook | Translation, prioritized gaps, and research roadmap |

Retain a standalone methods section when readers need it to judge whether results across studies are comparable.

## Phase 8: Figure strategy

Route submission-grade scientific figures through `nature-figure` when available. Match the production method to the evidence type:

| Figure type | Preferred source or method |
|---|---|
| Conceptual structure or mechanism | Author-created schematic with cited evidence and explicit synthesis label |
| Quantitative chart | Replotted source data or validated analysis; never invented values |
| Comparison matrix | Table or precisely constructed vector graphic |
| Empirical image | Lawfully reused or adapted published evidence with attribution and permission checks |

Rules:

- Do not generate data-like charts from prose.
- Label multi-source conceptual figures as conceptual synthesis and cite supporting sources.
- Keep captions and citations editable rather than baking them into raster images.
- Inspect every figure for scientific, typographic, and citation accuracy.
- Place a figure near the paragraph where it is first interpreted.

## Phase 9: Chinese review style

Load `references/chinese-review-writing-style.md`. In particular:

- keep one analytical point per paragraph;
- replace filler transitions with explicit logical relations;
- report numbers, conditions, and uncertainty instead of unsupported intensifiers;
- distinguish reported fact, author interpretation, and hypothesis;
- use scientific section titles rather than metaphors or journalistic phrasing.

## Phase 10: Table-as-figure substitution

Use a table when a conceptual diagram becomes too dense, decorative, or ambiguous. Tables are often better for causal-chain comparisons, theory contrasts, evidence matrices, and processes that require source attribution in every row.

Decision rule:

- spatial structure or compact mechanism → schematic;
- quantitative relationship → validated chart;
- multi-attribute comparison or citation-dense process → table;
- no traceable evidence → omit the visual or label it explicitly as a hypothesis.

## Pitfalls

1. Organizing by author, laboratory, or material without a cross-cutting analytical structure.
2. Treating a search miss as proof of a field-level gap.
3. Fixing the outline before understanding the literature landscape.
4. Using raw reference counts as a substitute for coverage quality.
5. Creating categories that overlap without stating their boundaries.
6. Adding figures that imply empirical support where none exists.
7. Hiding methodological incomparability inside a narrative synthesis.
8. Writing an outlook that says only “more research is needed” rather than prioritizing dependencies and decisions.

After the framework passes review, use `compose-mode.md` for section drafting, `review-critique-methodology.md` for critical-depth QA, and `professor-dispatch.md` for targeted specialist review.

references/revise-mode.md›

# Revise mode

Use when the user provides existing proposal text, a paper or proposal section, or a full research-plan draft.

## Contents

- [Overview](#overview)
- [Step-by-step](#step-by-step)
- [Steps 1-4: Classification, claims, evidence, and structure](#step-1-classify-the-text)
- [Steps 5-7: Expert review, anti-slop, and revision brief](#step-5-professor-review)
- [Steps 8-9: Revision and rescoring](#step-8-revise)
- [Output files](#output-files)

## Overview

```text
classify text → extract claims → compare with canon/evidence → diagnose structure
→ professor review → anti-slop scan → revision brief → revise → rescore
```

Revise mode starts from existing text. It does not build foundation files from scratch — it either reads existing foundation files or extracts them from the text itself. If no foundation files exist, the first run of revise mode builds minimal `research_canon` and `evidence_table` from the text before diagnosing.

**Core rule**: diagnose before rewriting. Content before language. Never beautify unsupported claims.

---

## Step-by-step

### Step 1: Classify the text

**Input**: the full text the user provides (paragraph, section, or full document).

**Output**: classification and scope boundary.

| Classification | What it covers |
|---|---|
| `background` | 研究背景与意义 |
| `literature_review` | 国内外研究现状 |
| `research_question` | 科学问题与研究目标 |
| `objectives` | 研究目标 |
| `methodology` | 实验设计与方法 |
| `innovation` | 创新点 |
| `feasibility` | 可行性分析 |
| `schedule` | 研究计划与时间安排 |
| `expected_outcomes` | 预期结果 |
| `full_proposal` | 完整 proposal（多个上述章节） |

**Pitfalls**:
- Don't classify by section heading alone. A section titled "研究背景" that mostly discusses literature is `literature_review`, not `background`.
- If the user provides a single section from a larger document, ask only whether to review it locally or against the full proposal when that choice changes the diagnosis.
- For `full_proposal`, load `references/partial-proposal-scope.md` if the document is intentionally partial-stage (e.g., Part 1 only). Don't flag missing later-stage content as a defect.

### Step 2: Extract claims

**Input**: classified text.

**Output**: a claim list with context. For each key claim in the text:

```
Claim: [verbatim or paraphrased]
Location: [section, paragraph]
Type: evidence-backed / plausible-inference / hypothesis / unsupported
Evidence cited: [what the text cites, or "none"]
```

**Minimum**: extract ≥ 5 claims for a single section, ≥ 15 for a full proposal.

**Pitfalls**:
- Claim extraction is mechanical, not judgmental. Extract first, judge later. Don't skip claims that "seem fine."
- Claims can be implicit. "The melting point is around 200°C" is a claim even if buried in a methods paragraph.
- Numerical claims are especially important to extract — they are the most likely to be overstated.

### Step 3: Compare claims with canon/evidence

**Input**: extracted claims, `01_research_canon.md` and `02_evidence_table.md` (if they exist). If they don't exist, build minimal versions from the text itself — this will expose internal inconsistencies.

**Output**: a comparison table marking each claim:

| Claim | Canon match? | Evidence table match? | Issue |
|---|---|---|---|
| "液相线约为 198 °C" | Canon says: "~200 °C (model estimate)" | Not in evidence table | Precision overstated; needs model→estimate downgrade |
| "处理 A 可降低失效速率" | Canon says: "Study 2 reports a reduction under matched conditions" | evidence-backed | OK — claim is supported and within scope |

**Pitfalls**:
- Don't flag a claim as unsupported just because it's not in the evidence table. If the claim is backed by a cited source in the text, it's supported — check whether the source actually says what the claim asserts.
- Claims that cross the scope boundary are not "wrong" — they are "out of scope." If the document is Part 1, a claim about three-electrode electrochemistry belongs in "后续研究方向," not "当前研究内容." Flag these as scope violations, not factual errors.

### Step 4: Diagnose structure

**Input**: classified text, extracted claims, comparison table.

**Output**: structural diagnosis covering:

| Check | Question |
|---|---|
| Section order | Does background → gap → question → objectives → methods → outcomes flow logically? |
| Section integrity | Does each section do only its job, or does background bleed into methods, methods into expected outcomes? |
| Argument presence | Is there a research question? Is it answered (or addressed) by the methods? |
| Claim distribution | Are evidence-backed claims concentrated in literature review, hypotheses in methods, unsupported in expected outcomes? (This is the expected pattern.) |
| Missing sections | For `full_proposal`: are any standard sections missing? Is the gap justified (e.g., partial-stage scope)? |

**Diagnose, don't fix yet.** The revision brief will prescribe fixes.

### Step 5: Professor review

**Input**: structural diagnosis, claim comparison, the text itself.

**Process**: if the structural diagnosis reveals non-trivial content risks (unsupported claims in key positions, scope violations, argument gaps), dispatch professor with 1-2 specialists. See `references/professor-dispatch.md`.

**Output**: expert reviews in `qa_logs/professor_round_XX.md`.

**Skip professor if**:
- The text has only language-level issues (anti-slop, long sentences).
- The structural diagnosis found no content-level problems.
- The user explicitly says "只看语言."

### Step 6: Anti-slop scan

**Input**: the text.

**Process**: scan for patterns listed in `references/research-anti-slop.md`. Mark each occurrence with:
- Type (empty significance / unsupported intensifier / mechanical structure / structural anti-pattern)
- Location
- Suggested fix

**Pitfalls**:
- Anti-slop fixes must not change scientific meaning. "显著降低腐蚀速率" cannot become "可能降低腐蚀速率" if the source paper reports statistical significance. When in doubt, preserve the original claim strength.
- Don't flag formulaic connectors that serve a genuine logical function. "首先…其次…" in a methods section describing a procedure sequence is fine. The same pattern in a background section is likely scaffolding.

### Step 7: Generate revision brief

**Input**: all diagnosis outputs (claim comparison, structural diagnosis, professor review, anti-slop scan).

**Output**: `revision_briefs/brief_round_XX.md` with:

| Section | Content |
|---|---|
| Overall assessment | 2-3 sentences; current score estimate; whether the text is at draft/internal/supervisor/polish level |
| Priority problems | P0 (block submission) / P1 (strongly recommended) / P2 (optimization), each with specific location and proposed fix |
| What NOT to change | parts of the text that work well — prevent over-revision |
| Suggested revision order | which problems to fix first |

**Pitfalls**:
- Don't generate a revision brief that says "rewrite everything." If the text is fundamentally broken, say so and recommend compose mode instead.
- Every P0 item must cite a specific paragraph or claim. "改进实验设计" is not actionable. "§3.3.4 纯化后取样环节未说明气氛控制" is.
- Include "what NOT to change" even for weak texts. Preserving what works builds trust and prevents revision fatigue.

### Step 8: Revise

**Input**: the text, the revision brief.

**Process**: apply fixes in priority order. After each major fix, spot-check that the fix didn't introduce new problems (e.g., fixing a claim downgrade didn't break the surrounding paragraph's logic).

**Rules**:
- Don't rewrite sections that are not flagged in the revision brief.
- Unsupported claims: mark, downgrade, or request evidence. Never silently upgrade.
- If a fix requires new evidence, update `02_evidence_table.md`.
- If a fix changes the scope boundary, update `00_scope.md`.

### Step 9: Rescore

**Input**: revised text.

**Process**: run the full evaluation rubric on the revised text. Compare scores to pre-revision scores.

**Output**: updated scores in `qa_logs/score_round_XX.md`.

**Gate**: if `proposal_score < 7.0` and stopping rules allow another round, return to Step 7 (revision brief). If stopping rules trigger, report status and escalate.

---

## Output files

```text
qa_logs/diagnosis_round_XX.md      — claim comparison + structural diagnosis
qa_logs/professor_round_XX.md      — expert reviews (if professor invoked)
qa_logs/anti_slop_round_XX.md      — anti-slop scan results
revision_briefs/brief_round_XX.md  — revision brief
drafts/revised_vX.md               — revised text
qa_logs/score_round_XX.md          — pre/post scores
```

references/stopping-rules.md›

# Stopping rules

Stop rather than continue polishing when any condition holds:

```text
max 3 revision rounds reached
two consecutive score improvements < 0.5
evidence needed for a key claim is missing
specialist conflict cannot be honestly resolved
The user's target for the current deliverable is reached
```

When stopping, report:

1. Current score/status
2. Remaining problems
3. Why the loop stopped
4. One recommended next action

Do not hide unresolved evidence gaps with smoother prose.

references/validation-checklist.md›

# Gate 3 — Auto-Validation Checklist

研究文本完成后自动检查的清单。每项必须通过，不通过标注缺失项。

## 必检项

### 引用完整性
- [ ] 每个事实性 claim 有 citation
- [ ] 所有 citation 在参考文献列表中存在
- [ ] 所有参考文献在正文中被引用
- [ ] 关键数值/参数有出处（腐蚀速率、温度、组成等）

### 方法可复现性
- [ ] 材料/试剂有品牌、纯度、批号（如适用）
- [ ] 设备有型号和关键参数
- [ ] 实验条件完整：温度、时间、气氛、压力
- [ ] 重复次数明确
- [ ] 统计方法注明
- [ ] 异常值剔除标准定义

### 术语定义
- [ ] 所有缩写首次出现有全称
- [ ] 领域特定术语首次出现有定义或引用来源
- [ ] 变量/符号有说明

### 逻辑链
- [ ] Introduction 提出的问题在 Discussion 有回应
- [ ] 每个目标/假设有对应的实验/分析来验证
- [ ] 结论不超出数据支持范围
- [ ] "本研究首次"等 novelty claim 有文献支撑

### 图表
- [ ] 编号连续
- [ ] 交叉引用正确
- [ ] 每个图/表有标题
- [ ] 坐标轴有标签和单位
- [ ] 图例清晰

### 格式
- [ ] 参考文献格式一致
- [ ] 数字/单位格式统一（如 °C vs ℃ vs deg C）
- [ ] 化学式上下标正确（MgCl₂ 不是 MgCl2）

## 估值方式

- 每项通过 = ✅
- 缺失但可快速补 = ⚠️ + 注明缺失项
- 结构性缺失 = ❌ → 不通过，定向回退

## 与中文/英文的差异

英文论文额外检查：
- [ ] 拼写和语法
- [ ] 时态一致性（Methods 用过去式，Results 用过去式，Discussion 可混合）

中文论文额外检查：
- [ ] "的"字冗余（连续多个"的"）
- [ ] 欧化句式（过长的定语从句）

references/within-approved-proposal.md›

# 提案内写作：在已立项本子框架内深化研究计划

当用户在已立项项目框架下写研究计划——本子已批，不能改立意，但可以加深和细化执行方案。

## 触发条件

- 用户说"本子下来了""他们申请的，我需要按照本子写研究计划"
- 用户不能分享完整本子（敏感材料），只能复制片段
- 本子有固定章节结构、研究内容分块、明确的分工（你的课题 vs. 别人的课题）
- 用户说"不要标新立异""不能改变立意"

## 与 compose 模式的差异

| 维度 | 标准 compose | 提案内写作 |
|---|---|---|
| 研究问题来源 | 从文献空白凝练 | 本子已给定，可深化但不可改写 |
| 研究内容结构 | 自由设计 | 本子子内容固定，在本子框架内填充 |
| 创新点 | 独立论证 | 作为自然组成嵌入，不另立旗帜 |
| 科学张力 | 自建 narrative arc | 在本子已有张力基础上深化 |
| 参考文献库 | 自由检索 | 本子已有文献 + 用户自有综述 |
| 写作边界 | 用户定义 | 本子划定，超出需确认 |

## 信息接收阶段

本子内容通常是片段式接收的（用户复制粘贴各节），需要：

1. **先收全再分析**：确认收到摘要、研究现状（你的部分）、研究内容、研究目标、关键科学问题、研究方法、技术路线、创新点、预期成果后再开始规划
2. **标注每条信息的来源位置**：摘要 → §0；研究内容 → §3.2.3；方法 → §4.1.4 等，方便后续引用
3. **识别分工边界**：明确哪些内容属于其他工作包、哪些属于当前作者，避免越界
4. **提取硬约束**：性能指标、禁用表述、材料或工况范围、格式要求

## 写作策略

### 1. 在本子框架内深化，不另起炉灶

- 研究内容编号与本子一致（如“3.2.3 (1) 关键变量”）
- 使用本子已经定义的术语体系，不擅自更名或重新分组
- 引用本子已有文献时标注"[n]"（对应本子参考文献编号）
- 不在科学问题层面"超越"本子——本子的科学问题是团队的，你的是课题三的具体化

### 2. 加法放在执行层面

本子通常在研究方案层面较空泛（"采用……等方法，研究……"），你的加法空间在：
- **实验矩阵**：具体梯度、平行样数、温度点、时间点
- **方法细节**：电极材料、电位参数、气氛配比、表征手段组合
- **判断标准**：什么算成功、什么算失败、失败后怎么办
- **独立执行策略**：不依赖其他课题尚未产出的数据

### 3. 自己的武器自然嵌入

你有而本子没有的方法，不要单独成章标新立异，而是：
- 作为既有研究任务的一种候选手段嵌入
- 作为效果评价或状态监测工具嵌入
- 在技术路线中作为自然的方法组合出现
- 用“参照既有方法，探索在目标体系中的适用性”而非“本研究首创”

### 4. 独立执行策略必须有

如果本子包含多条并行主线，当前研究计划必须写明：
- 输入样品或数据如何独立获得，不依赖其他工作包尚未产出的结果
- 关键模型参数和边界条件从哪里获得
- 实验或评价在哪个平台完成
- 其他工作包数据产生后如何交叉验证，而不是把它们设为前置依赖

## Foundation 文件注意事项

- `01_research_canon.md` 需双重来源：文献事实 + **本子约束**（作为独立一节）
- `02_evidence_table.md` 中标注哪些 claim 来自本子、哪些来自用户自有综述、哪些是推论
- `03_argument_map.md` 的科学张力从本子已有空白出发，不另造张力
- `04_section_contracts.md` 的研究内容编号与本子保持一致
- `05_style_guide.md` 强调"不另立旗帜""不声称首创"

## 常见陷阱

1. **把本子当文献综述用**：本子是项目申报书，不是发表的论文——引用时标注"（本子 §X.X）"，不要把它当已发表文献引用
2. **越界到其他工作包**：不要在当前方案中替其他负责人设计实验或承诺交付
3. **把假设写成结论**：本子中标记为“尚待验证”的路线，在研究计划中仍是待验证假设，不能写成“将建立”
4. **忘记兜底**：探索性方法（如电化学纯化）必须有失败兜底方案
5. **博士生不等于项目负责人，预期成果不照搬项目 KPI**：论文数、专利数或人员培养数可能是项目总指标，不一定适合作为个人研究计划的科学交付。优先写数据集、方法、工艺方案或判据等研究层面产出。
6. **不可行的技术路径退出主线**：当证据表明某条路线不可行时，从核心目标和交付中删除或明确降级。是否在正文解释失败原因取决于文本目的；不得用额外文字把已否定路线包装成可交付主线。

references/worked-example-quaternary-proposal.md›

# Worked example: materials proposal revise-mode evaluation

This fictionalized example shows the expected depth of a revise-mode assessment without relying on a real project, person, or file path.

- **Mode**: revise
- **Text type**: doctoral proposal, first stage
- **Domain**: multicomponent high-temperature materials system

## Pipeline flow applied

1. Classify text → background and literature review, objectives, methodology, expected outcomes, and references.
2. Extract claims → scan each paragraph for scientific and feasibility claims.
3. Compare with canon → check every claim against literature, model boundaries, and supervisor constraints.
4. Diagnose structure → identify the strongest argument chain and sections overloaded with conditional outcomes.
5. Run anti-slop scan → check structural and language anti-patterns.
6. Score → assess all eight rubric dimensions independently.
7. Write revision brief → separate P0, P1, and P2 changes and state what should remain unchanged.

## Illustrative scoring

| Dimension | Score | Evidence-based reason |
|---|:---:|---|
| Research-question clarity | 7 | The question is identifiable but buried in the background. |
| Scientific tension | 8 | A real trade-off between performance and compatibility drives the project. |
| Evidence alignment | 6 | Model outputs are reported with more precision than the source figure supports. |
| Logic chain | 8 | The sequence from system limitation to candidate intervention is coherent. |
| Method feasibility | 6 | Atmosphere control and transition steps are underspecified. |
| Novelty | 6 | The contribution is implicit and not yet distinguished from the closest work. |
| Risk boundaries | 7 | Conditional outcomes are present, but the all-candidates-fail route is missing. |
| Language quality | 7 | No major template language, but the outcomes section is repetitive. |

Overall score: **6.9/10**. The draft is suitable for supervisor discussion after P0 fixes, but not ready for formal submission.

## Constraint checklist

Before revising prose, verify every project constraint explicitly:

- candidate selection is traceable to evidence or a declared model;
- environment and exposure controls are specified;
- material or sample categories match the approved scope;
- experimental flows are distinguishable and reproducible;
- later-stage platform work remains deferred;
- model outputs are labeled as predictions rather than measurements.

## What to watch for

### Unverifiable embedded figures

If a figure cannot be inspected, do not infer its content from the caption alone. Extract it with an appropriate document workflow, or report that figure-level verification remains incomplete.

### Precision inflation

Flag model or plot-derived values reported to more significant figures than the source supports. Prefer an approximate value, range, or uncertainty statement.

### Transition-step gaps

A flow such as “cool → sample → insert specimen → reheat” must specify environment control during every intermediate step. Transition steps often contain the highest contamination and reproducibility risk.

## Revision brief format

```markdown
## Revision Brief

### P0 — must fix
1. [Location] — [Problem] — [Required change] — [Acceptance criterion]

### P1 — strongly recommended
...

### P2 — optional optimization
...

### Preserve
- [Elements that already work and should not be rewritten]
```

Each item must identify a location, explain why the issue matters, prescribe a concrete change, and define how the revised text will be checked.

references/降承诺提案模式.md›

# 降承诺提案模式（De-commit Pattern）

当 proposal 在已立项本子框架内写作时，最常犯的错误是把"探索方向"写成"核心交付"。降承诺不是删内容，是把承诺等级校准到证据强度。

## 触发条件

- 本子已立项，proposal 在本子框架内深化
- 体系存在根本性的理论、化学、工程或伦理约束，使原定路线无法支撑高强度承诺
- 导师有明确的"不要标新立异"要求

## 三层承诺等级

| 等级 | 定义 | 写法 |
|---|---|---|
| **可交付主线** | 文献充分支持 + 实验条件具备 → 必须做到 | "建立...""确定..." |
| **审慎探索** | 有文献线索但体系迁移风险高 → 试，不保证 | "探索...的可行性""验证...是否成立" |
| **边界确认** | 只回答"能不能做"，不追求优化 | "确定...的操作窗口和 Go/No-Go 判据" |

## 操作步骤

1. **列出所有 claim**，给每个打承诺等级
2. **主线收缩**：只保留可交付主线作为核心产出
3. **探索降级**：原"核心创新"降到"审慎探索"，加失败判据和兜底方案
4. **边界显式化**：明确写出"如果 X 不可行 → 退回 Y 路线"
5. **主线句重写**：全文定位句必须反映降级后的承诺结构

## 通用案例：高风险干预路线

**降级前**：方法 X 是核心路线，将实现对目标变量的主动控制并形成稳定工艺。

**降级后**：方法 X 用于状态识别和可行性边界确认；只有在 Go/No-Go 判据通过后，才进入主动控制和工艺优化。

**逻辑链**：

- 现有文献仅证明方法 X 能测量相关状态；
- 在目标体系中，干预过程可能同时改变关键边界条件；
- 当前证据不能区分目标效应与系统扰动；
- 因此先把方法 X 定位为监测和边界验证工具，并保留证据充分的基线方案作为主线。

## 配合 professor 审查的完整工作流

```
proposal 初稿 → professor Convener（2-3 专家）
    → 修订简报（P0/P1/P2 分级）
    → 用户讨论 + 方向确认
    → 修改指令 → 外部编辑器（GPT/Codex）
    → 用户自改
    → 最终稿
```

不是每个 proposal 都需要跑完这整条链——只有 professor 审查发现 P0 级承诺问题时才启动降承诺流程。

scripts/build_proposal_docx.py›

#!/usr/bin/env python3
"""Convert researchwrite proposal markdown to properly formatted .docx.

Usage: python3 scripts/build_proposal_docx.py <input.md> [output.docx]

Formatting standard for academic proposals:
- Title: centered, Times New Roman + 宋体, 18pt bold
- Headings: Times New Roman + 宋体, 16/14/12pt bold, black
- Body: Times New Roman + 宋体, 12pt, 1.5 line spacing, NO first-line indent
- Margins: 1 inch all sides
- Tables: 10pt, Table Grid style
"""
import sys
from docx import Document
from docx.shared import Pt, Cm, RGBColor, Inches
from docx.enum.text import WD_ALIGN_PARAGRAPH
from docx.oxml.ns import qn
import re

inpath = sys.argv[1]
outpath = sys.argv[2] if len(sys.argv) > 2 else inpath.replace('.md', '.docx')

doc = Document()

# Page setup
for section in doc.sections:
    section.top_margin = Inches(1.0)
    section.bottom_margin = Inches(1.0)
    section.left_margin = Inches(1.0)
    section.right_margin = Inches(1.0)

# Normal style
style = doc.styles['Normal']
style.font.name = 'Times New Roman'
style.font.size = Pt(12)
style.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
pf = style.paragraph_format
pf.line_spacing = 1.5
pf.space_before = Pt(0)
pf.space_after = Pt(0)
pf.first_line_indent = Cm(0)

# Heading styles
for level, size in [(1, 16), (2, 14), (3, 12)]:
    hs = doc.styles[f'Heading {level}']
    hs.font.name = 'Times New Roman'
    hs.font.size = Pt(size)
    hs.font.bold = True
    hs.font.color.rgb = RGBColor(0, 0, 0)
    hs.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    hs.paragraph_format.line_spacing = 1.5
    hs.paragraph_format.space_before = Pt(18 if level == 1 else 12 if level == 2 else 6)
    hs.paragraph_format.space_after = Pt(12 if level == 1 else 6 if level == 2 else 3)


def bp(text, bold=False, size=12, italic=False, color=None):
    p = doc.add_paragraph(style='Normal')
    run = p.add_run(text)
    run.font.name = 'Times New Roman'
    run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    run.font.size = Pt(size)
    run.bold = bold
    run.italic = italic
    if color:
        run.font.color.rgb = color
    return p


def bullet(text, level=0):
    p = doc.add_paragraph(style='Normal')
    p.paragraph_format.left_indent = Cm(1.0 + level * 0.5)
    run = p.add_run('• ' + text)
    run.font.name = 'Times New Roman'
    run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    run.font.size = Pt(11)


def numbered(text):
    p = doc.add_paragraph(style='Normal')
    p.paragraph_format.left_indent = Cm(1.0)
    run = p.add_run(text)
    run.font.name = 'Times New Roman'
    run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    run.font.size = Pt(11)


def table(headers, rows):
    t = doc.add_table(rows=len(rows) + 1, cols=len(headers))
    t.style = 'Table Grid'
    for i, h in enumerate(headers):
        cell = t.rows[0].cells[i]
        cell.text = ''
        p = cell.paragraphs[0]
        p.paragraph_format.first_line_indent = Cm(0)
        run = p.add_run(h)
        run.font.size = Pt(10)
        run.font.bold = True
        run.font.name = 'Times New Roman'
        run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    for r, row in enumerate(rows):
        for c, val in enumerate(row):
            cell = t.rows[r + 1].cells[c]
            cell.text = ''
            p = cell.paragraphs[0]
            p.paragraph_format.first_line_indent = Cm(0)
            run = p.add_run(val)
            run.font.size = Pt(10)
            run.font.name = 'Times New Roman'
            run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
    doc.add_paragraph()


# Parse markdown
with open(inpath, encoding='utf-8') as f:
    lines = f.readlines()

i = 0
in_code = False
code_buf = []
first_title = True

while i < len(lines):
    line = lines[i].rstrip('\n')

    if not line.strip():
        i += 1
        continue

    if line.strip().startswith('```'):
        if in_code:
            txt = '\n'.join(code_buf)
            p = doc.add_paragraph(style='Normal')
            p.paragraph_format.left_indent = Cm(1.0)
            run = p.add_run(txt)
            run.font.name = 'Consolas'
            run.font.size = Pt(9)
            code_buf = []
            in_code = False
        else:
            in_code = True
        i += 1
        continue

    if in_code:
        code_buf.append(line)
        i += 1
        continue

    if first_title and line.startswith('# ') and not line.startswith('## '):
        title_text = line[2:].strip()
        p = doc.add_paragraph(style='Normal')
        p.alignment = WD_ALIGN_PARAGRAPH.CENTER
        run = p.add_run(title_text)
        run.bold = True
        run.font.size = Pt(18)
        run.font.name = 'Times New Roman'
        run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
        first_title = False
        i += 1
        continue

    if line.startswith('# ') and not line.startswith('## '):
        doc.add_heading(line[2:].strip(), level=1)
        i += 1
        continue

    if line.startswith('## ') and not line.startswith('### '):
        doc.add_heading(line[3:].strip(), level=2)
        i += 1
        continue

    if line.startswith('### ') and not line.startswith('#### '):
        doc.add_heading(line[4:].strip(), level=3)
        i += 1
        continue

    if line.startswith('#### '):
        p = doc.add_paragraph(style='Normal')
        run = p.add_run(line[5:].strip())
        run.bold = True
        run.font.size = Pt(12)
        run.font.name = 'Times New Roman'
        run.element.rPr.rFonts.set(qn('w:eastAsia'), '宋体')
        i += 1
        continue

    if line.strip() == '---':
        doc.add_paragraph()
        i += 1
        continue

    if line.strip().startswith('|') and not line.strip().startswith('|---'):
        tbl_lines = [line]
        j = i + 1
        if j < len(lines) and '|---' in lines[j]:
            j += 1
        while j < len(lines) and lines[j].strip().startswith('|'):
            tbl_lines.append(lines[j].rstrip('\n'))
            j += 1
        if len(tbl_lines) >= 2:
            headers = [c.strip() for c in tbl_lines[0].split('|')[1:-1]]
            rows = [[c.strip() for c in l.split('|')[1:-1]] for l in tbl_lines[1:]]
            table(headers, rows)
        i = j
        continue

    if line.strip().startswith('**') and line.strip().endswith('**'):
        bp(line.strip()[2:-2], bold=True)
        i += 1
        continue

    if line.strip().startswith('- '):
        bullet(line.strip()[2:])
        i += 1
        continue

    if re.match(r'^\d+\.', line.strip()):
        numbered(line.strip())
        i += 1
        continue

    if line.startswith('>'):
        bp(line[1:].strip(), italic=True, size=10, color=RGBColor(80, 80, 80))
        i += 1
        continue

    bp(line.strip())
    i += 1

doc.save(outpath)
print(f"OK → {outpath}")

SKILL.md›

---
name: researchwrite
description: |
  Proposal-first scientific writing pipeline, installed under the compatibility trigger researchwrite and the repository package name nature-proposal-writer. Use for composing, revising, or auditing research proposals, opening reports, research plans, and evidence-grounded scientific writing. Three modes (compose/revise/hybrid) with a four-layer QA pipeline. Enforces evidence-before-prose, argument-before-sections, and contracts-before-paragraphs.
license: MIT
metadata:
  hermes:
    tags: [research, writing, proposal, revision, qa, multi-agent]
    related_skills: [brainstorming, professor, avoid-ai-writing, docx]
---

# researchwrite — proposal-first 科研写作 pipeline

受 autonovel（状态机+打分）、professor（动态专家）、brainstorming（入口追问）、anti-AI-writing（语言清理）启发的科研写作状态机。**不是通用"帮我写论文"prompt。**

`researchwrite` 是为兼容既有安装保留的触发名称，仓库目录名仍为
`nature-proposal-writer`。不要在没有迁移方案时修改 frontmatter 名称。需要初始化模板、
按条件加载参考资料或执行导出脚本时，先读取 `manifest.yaml`，只加载与当前条件匹配的路径。

## 核心原则

1. **证据先于文字** — 起草前必须建立或读取 `research_canon` 和 `evidence_table`
2. **论证先于章节** — 写正文前必须完成 `argument_map`
3. **契约先于段落** — 每节需要 purpose / allowed claims / forbidden claims / inputs / validation
4. **范围先于完备** — 如果是分阶段写作，先锁定阶段边界
5. **动态专家，不设固定池** — 用 `professor` 按失败模式召唤对应专家
6. **内容先于语言** — 诊断科学逻辑后再做 anti-slop / 语言打磨
7. **不自动升级事实** — 永远不把 "may indicate" 改成 "proves"，除非有证据支撑
8. **删除胜于解释** — 当某主张不可行，直接删除。正文干净，解释留给答辩
9. **该停就停** — 平台期、专家冲突、证据缺失是停止理由，不是润色理由

## 模式分派

| 输入 | 模式 |
|---|---|
| 题目、方向、模糊想法 | `compose` — 加载 `references/compose-mode.md` |
| 已有段落/章节/完整 proposal | `revise` — 加载 `references/revise-mode.md` |
| 已有草稿 + 扩写/补写/重构 | `hybrid` — 加载 `references/hybrid-mode.md` |

模糊时推断默认模式。只在选择会改变工作流时才问用户。

## 项目结构

**工作目录**：`<outputs>/researchwrite/<project-slug>/`

**标准文件**：

```
00_scope.md              写作任务边界
01_research_canon.md     硬事实和约束
02_evidence_table.md      claim → evidence 映射表
03_argument_map.md        论证架构
04_section_contracts.md   每节的 purpose / inputs / allowed & forbidden claims
05_style_guide.md         风格、术语、禁用表达
state.json                项目状态（mode、round、scores、technical_debts）
sources/                  用户材料、文献、数据
drafts/                   草稿和分节文件
revision_briefs/          修订简报
qa_logs/                  诊断、专家审查、anti-slop、打分记录
exports/                  最终输出（.md + .docx）
```

新建项目时按 `manifest.yaml` 的 `templates.on_demand` 路由从 `templates/` 取空模板。
`references/worked-example-quaternary-proposal.md` 提供了基于通用材料科学领域的完整填写示例。

## Reference 文件索引

完整 reference 按任务需要加载，不要一次性注入全部文件：

| Reference | 加载时机 |
|---|---|
| `references/compose-mode.md` | 模式 = compose（9 步流程） |
| `references/revise-mode.md` | 模式 = revise（9 步流程） |
| `references/hybrid-mode.md` | 模式 = hybrid |
| `references/evaluation-rubric.md` | 使用 8 维 × 4 锚点评分体系时 |
| `references/research-anti-slop.md` | 清理中文 proposal 的模板化和空泛表达时 |
| `references/chinese-review-writing-style.md` | 撰写或修订中文综述时 |
| `references/stopping-rules.md` | 判断继续迭代、拆分范围或停止时 |
| `references/professor-dispatch.md` | 按失败模式分派动态专家时 |
| `references/foundation-files.md` | 建立或修复 foundation 五文件时 |
| `references/project-structure.md` | 初始化项目目录或维护 `state.json` 时 |
| `references/export-archive.md` | 导出和归档 `.md` / `.docx` 时 |
| `references/partial-proposal-scope.md` | 分阶段写作并防止范围蔓延时 |
| `references/ref-renumbering-cascade.md` | 处理参考文献增删和编号级联时 |
| `references/review-paper-framework.md` | 设计综述论文框架时 |
| `references/review-critique-methodology.md` | 建立综述的批判性分析时 |
| `references/validation-checklist.md` | 自动检查主张、引用、编号和可复现性时 |
| `references/gpt-handoff-revision-brief.md` | 生成跨 agent 修订交接简报时 |
| `references/within-approved-proposal.md` | 在已批准的 proposal 框架内扩写时 |
| `references/worked-example-quaternary-proposal.md` | 需要查看完整 foundation 文件填写示例时 |
| `references/降承诺提案模式.md` | 证据不足，需要降低承诺强度时 |

## 运行交付

每次运行结束时输出：

1. 当前文件路径或修订后文本
2. 当前分数/状态
3. 剩余风险
4. 一条建议的下一步

## QA Mode — 四层质量保障 Pipeline

当用户说"审查这段/跑 QA/检查方案/过 pipeline"时，进入 QA 模式。

### 情境挡位

| 挡位 | 适用场景 | 阈值 |
|------|---------|------|
| `paper` | 投稿论文 | 7.0 |
| `proposal` | 研究方案/开题 | 7.0 |
| `internal` | 内部汇报/周报 | 5.0 |
| `quick` | 快速扫读 | 无 |

### Pipeline 顺序（先内容后语言）

```
Gate 2: professor Convener（内容层）
  ├── 论文 → 方法论专家 + 领域专家
  ├── proposal → 可行性专家 + 创新性专家
  └── 文献综述 → 覆盖面专家 + 批判深度专家
  │
  ▼
Gate 1: avoid-ai-writing 模式 detect-only
  └── 只对英文有效，中文跳过或降级为手工扫读
  │
  ▼
Gate 3: auto-validation（格式/完整性层）
  └── 每个 claim 有 citation？方法可复现？编号连续？
  │
  ▼
Gate 4: 评分阈值（分维度打分）
  ├── 总分≥阈值 → 通过 ✅
  └── 总分<阈值 → 按低分维度定向回退（不超过 3 轮）
```

**Gate 2 在 Gate 1 之前** — 避免改了句子后被专家打回重写。

### 使用方法

```
用户: "用 researchwrite 审查这段 discussion，paper 挡位"
  → 自动走 Gate 2 → Gate 1 → Gate 3 → Gate 4
  → 返回审查报告 + 定向修改建议

用户: "快速扫一下这个邮件"
  → 走 quick 挡位，只标记 P0 问题
```

## 配置你的研究域

首次使用告诉 agent 你的研究背景，agent 会调用 `professor` 建立领域专家知识。后续写作中专家审查会基于你的领域。

templates/00_scope.md›

# Scope

- Project:
- Mode: compose / revise / hybrid
- Text type: doctoral proposal / proposal section / research plan
- Target reader:
- Language: zh / en / mixed
- Deliverable scope:
- Desired version: rough draft / supervisor-facing / final polish
- Constraints:
- Vault access allowed: yes / no
- Archive after confirmation: yes / no

templates/01_research_canon.md›

# Research canon

## Literature facts

## Experimental facts

## Thermodynamic / model facts

## Supervisor constraints

## Terminology definitions

## Forbidden claims

## Unresolved claims

templates/02_evidence_table.md›

# Evidence table

| Claim | Evidence/source | Strength | Usable section | Risk | Status |
|---|---|---|---|---|---|
|  |  | evidence-backed / plausible-inference / hypothesis / unsupported |  |  |  |

templates/03_argument_map.md›

# Argument map

## Scientific tension

- What is known:
- What is unknown:
- Why the gap matters:

## Central research question

## Central thesis

## Supporting arguments

### Argument 1
- Claim:
- Evidence:
- Limitation:

### Argument 2
- Claim:
- Evidence:
- Limitation:

### Argument 3
- Claim:
- Evidence:
- Limitation:

## Counterarguments / alternative explanations

## Final move

templates/04_section_contracts.md›

# Section contracts

## Section: 

- Purpose:
- Inputs:
- Allowed claims:
- Forbidden claims:
- Required evidence:
- Validation checklist:

templates/05_style_guide.md›

# Style guide

- Language:
- Target reader:
- Tone: conservative / innovation-forward / engineering-feasibility / scientific-question-driven
- Terminology:
- Forbidden expressions:
- Supervisor preferences:
- Citation style:

templates/qa_report.md›

# QA report

- Round:
- Mode:
- Text type:

## Scores

| Dimension | Score | Notes |
|---|---:|---|
| 研究问题清晰度 |  |  |
| 科学张力 |  |  |
| 证据匹配 |  |  |
| 逻辑链 |  |  |
| 方法可行性 |  |  |
| 创新性 |  |  |
| 风险边界 |  |  |
| 语言质量 |  |  |

## Main risks

## Required fixes

## Recommendation

templates/revision_brief.md›

# Revision brief

- Round:
- Target text:
- Current score:
- Main problems:
- Required changes:
- Claims to downgrade/remove:
- Evidence needed:
- Language cleanup:
- Stop condition check: